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ABSTRACT 


The  budget  to  build  ships  and  modernize  and  sustain  the  C4I  systems  installed  is  limited. 
Lead  times  for  eontracting  are  long,  while  technology  changes  rapidly  after  contract 
award.  The  shipboard  C4I  network  examined  in  this  thesis  typifies  this  dichotomy.  The 
challenge  is  to  provide  the  latest  shipboard  network  that  meets  the  C4I  capability  needs  of 
the  warfighter  at  ship  delivery,  while  at  the  same  time  supporting  the  shipbuilder’s  need 
for  Government  Furnished  Information  (GFI)  and  Government  Furnished  Equipment 
(GFE)  supporting  the  Ship  Construction  schedule. 

This  thesis  analyzes  whether  to  install  the  legacy  Shipboard  Wide  Area  Network 
(SWAN),  where  the  GEI  is  firm,  or  install  the  newer  Consolidated  Afloat  Network 
Enterprise  System  (CANES),  where  the  GEI  is  evolving,  on  LPD  28  during  New  Ship 
Construction.  Recommendations  include  implementation  of  the  Design  Budget  Approach 
during  New  Ship  Construction,  use  of  the  Systems  Engineering  (SE)  V  Method  during 
C4I  network  system  development  to  verify  and  validate  warfighter  requirements  can  be 
met,  and  a  commitment  to  the  GEE  Program  of  Record  (POR)  C4I  network  solutions. 
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EXECUTIVE  SUMMARY 


The  Shipboard  Wide  Area  Network  (SWAN)  has  been  installed  on  the  first  10  ships  of 
the  LPD  17  Class  and  is  currently  being  installed  on  LPD  27.  However,  with  the  recent 
decision  by  Congress  to  authorize  funding  for  LPD  28,  the  Navy  has  the  opportunity  to 
implement  the  LPD  17  SWAN  Sustainment  study  recommendation  to  federate  the 
SWAN  network  and  install  the  Consolidated  Afloat  Network  Enterprise  System 
(CANES),  as  opposed  to  SWAN  during  New  Ship  Construction  on  EPD  28. 

Ship  delivery,  which  is  a  shipbuilding  term  synonymous  with  commissioning,  for 
EPD  28  is  currently  planned  for  May  2022.  Since  it  typically  takes  about  seven  years 
from  contract  award  to  commissioning  for  a  ship  of  the  EPD  17  Class,  the  Request  for 
Proposal  (REP)  package,  which  must  include  detailed  design  information,  which  the 
shipbuilder  will  review  and  bid  on  in  support  of  contract  award,  is  expected  to  be  released 
to  industry  no  later  than  (NET)  October  2015. 

Since  an  EPD  17  Class  CANES  design  is  not  mature  at  this  time,  providing  firm 
GEI  to  the  shipbuilder  in  support  of  the  REP  package  release  creates  a  dilemma  for  the 
Department  of  the  Navy.  The  dilemma  is  whether  to  provide  the  older,  mature  design 
information  associated  with  the  SWAN,  for  which  the  shipbuilder  has  experience  with 
installing  vs.  allowing  flexibility  for  the  CANES  design  to  evolve  so  that  EPD  28  will 
deliver  to  the  Navy  a  current  C4I  network  in  2022.  As  CANES  will  go  through  at  least 
one  hardware  refresh  cycle  between  2017  and  2022,  the  importance  of  implementing  a 
flexible  design  approach  is  crucial  to  avoid  information  technology  obsolescence  issues 
at  ship  delivery.  This  is  situation  represents  a  challenge  that  the  Department  of  the  Navy 
has  faced  with  New  Ship  Construction  for  years,  as  systems’  complexity  and  technology 
has  advanced  this  question  arises:  What  is  the  best  way  to  meet  the  shipbuilder 
requirements  for  early  GEI,  while  at  the  same  time  allowing  for  advanced  information 
technology  to  continue  to  mature  so  that  the  ship,  when  completed  and  delivered  to  the 
Navy,  will  have  the  latest  technology  installed? 


This  research  addresses  this  question  and  provides  a  series  of  recommendations 
that  will  benefit  the  LPD  28  shipbuilding  effort  and  all  future  U.S.  Navy  ship 
construction. 

The  research  examines  the  previous  work  done  by  the  LPD  17  Class  SWAN 
Network  Sustainment  study  team.  This  thesis  includes  a  section  that  provides  an 
overview  of  the  SWAN,  the  Study  team’s  findings,  and  the  study  team’s  recommendation 
to  OPNAV. 

The  research  also  examines  the  shipboard  network  Capability  Need 
Determination  that  drove  the  genesis  of  the  CANES  acquisition  effort.  In  addition,  the 
research  examines  the  CANES  Key  Performance  Parameters  (KPPs)  Key  System 
Attributes  (KSAs),  and  the  CANES  Systems  Engineering  Process. 

Lastly,  the  research  provides  an  overview  of  the  Design  Budget  Process, 
including  the  core  tenets  of  Design  Budget  and  an  example  that  highlighted  the  benefits 
of  Design  Budget.  The  research  concludes  that  the  Department  of  the  Navy  should  make 
the  decision  to  install  CANES  on  LPD  28  during  New  Ship  Construction  by 
implementing  the  Design  Budget  Process  in  the  effort  to  mitigate  the  risk  of  C4I 
equipment  obsolescence  at  ship  delivery. 
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I.  INTRODUCTION 


A.  BACKGROUND 

In  the  late  1990s  and  early  2000s,  the  leadership  of  the  Department  of  the  Navy 
made  a  deeision  to  embrace  the  use  of  Electronic  Systems  Integrators  (ESIs)  from  the 
defense  industry  to  lead  the  effort  to  design,  develop,  test,  integrate,  install,  and  sustain 
Commercially  Eurnished  Equipment  (CEE)  networks  onboard  New  Construction  Ships 
still  in  the  early  development  phase.  Alliances  between  the  shipbuilders  and  major 
defense  contractors,  such  as  Eockheed-Martin,  Raytheon,  and  Northrop-Grumman 
emerged.  The  result  was  that  three  classes  of  new  construction  ships  were  delivered  to  the 
Navy  with  CEE  Networks  installed,  as  opposed  to  the  traditional  Government  Eurnished 
Equipment  (GEE)  Program  of  Record  (POR)  solution,  such  as  the  Integrated  Shipboard 
Network  System  (ISNS),  which  is  in  place  on  the  majority  of  U.S.  Navy  ships.  The  two 
primary  cases  of  CPE  networks  include  the  Shipboard  Wide  Area  Network  (SWAN), 
which  has  been  installed  on  the  previous  eleven  EPD  17  Class  ships,  and  the  Total  Ships 
Computing  Environment  (TSCE),  which  is  the  shipboard  network  installed  on  both  the 
DDG  1000  Class  ships  and  the  Eittoral  Combat  Ship  (ECS).  This  proliferation  of  CPE 
Networks  for  has  created  new  sustainability  challenges  that  the  Department  of  the  Navy 
must  face  for  the  EPD  17,  DDG  1000,  and  ECS  1  Class  ships.  The  purpose  of  this 
research  is  to  examine  the  sustainability  challenge  of  the  SWAN  and  provide  specific 
recommendations  for  the  future. 

The  speed  of  technological  change  in  Command,  Control,  Communications, 
Computers,  and  Intelligence  (C4I)  systems,  coupled  with  a  suboptimal  process  for 
integrating  C4I  systems  during  New  Ship  Construction,  has  created  a  situation  where  new 
ships  are  often  delivered  to  the  Navy  lacking  the  latest  in  C4I  capabilities.  This  is  due 
primarily  to  the  fact  that  New  Ship  Construction,  a  defense  acquisition  term  associated 
with  shipbuilding  that  is  sometimes  identified  as  Shipbuilding  and  Conversion,  Navy 
(SCN),  requires  that  specific  C4I  equipment  be  identified  at  least  one  year  prior  to  the 
contract  award  supporting  ship  construction.  After  the  contract  award,  ship  delivery  itself 
can  take  another  four  to  nine  years,  depending  on  the  type,  size,  and  complexity  of  the 
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ship  being  constructed.  This  early  requirement  to  identify  specific  C4I  equipment  has 
traditionally  resulted  in  brand  new  ships  being  delivered  to  the  Navy  with  dated  and  less 
than  optimal  C4I  equipment  suites  installed  onboard.  This  dynamic  of  rapid  changes  in 
technology,  coupled  with  high  profde  examples  of  new  construction  ships  being 
delivered  to  the  Navy  with  out  of  date  information  technology  systems  and  networks, 
created  an  opportunity  for  industry  to  propose  to  the  Department  of  the  Navy  leadership 
that  CFE  solutions  be  adopted  over  traditional  GFE  as  a  cost  savings  measure. 

With  C4I  equipment  being  predominantly  information  technology  based,  the 
impact  of  Moore’s  Eaw  is  highly  relevant  (Moore,  1965).  Exponential  improvements  in 
Informational  Technology-based  systems  are  having  a  direct  impact  in  how  the  Navy 
processes  information  onboard  ships,  airplanes,  and  submarines.  If  one  considers 
Moore’s  Eaw  in  the  context  of  the  length  of  time  it  takes  to  build  a  ship,  a  process  to 
improve  C4I  system  procurement,  delivery,  installation,  integration,  and  testing 
supporting  New  Ship  Construction  must  be  realized  to  avoid  the  risk  of  obsolescence. 

One  such  New  Ship  Construction  Program  is  the  EPD  17  SAN  ANTONIO  Class, 
which  consists  of  1 1  amphibious  transport  dock  ships  originally  designed  to  functionally 
replace  over  41  amphibious  ships  that  comprise  the  EPD  4,  ESD  36,  EKA  113,  and  EST 
1179  classes.  The  mission  of  the  EPD  17  Class  is  to  embark,  transport,  and  land  elements 
of  an  embarked  Landing  Force,  consisting  of  advanced  amphibious  assault  vehicles 
(AAAVs),  air-cushioned  landing  craft  (LCACs),  and  the  MV-22  Osprey  tilt-rotor  aircraft. 
The  EPD  17  Class’  increased  vehicle  space  and  substantial  cargo  carrying  capacity  makes 
the  ships  of  this  class  a  key  element  of  twenty-first  century  Amphibious  Readiness 
Groups,  Expeditionary  Strike  Groups,  or  Joint  Task  Forces. 

The  first  ship  of  the  class,  USS  SAN  ANTONIO  (EPD  17),  was  commissioned  in 
2006.  At  present,  LPDs  17  -  25  are  currently  in  service  to  the  U.S.  Navy  and  LPDs  26 
and  27  are  currently  under  construction.  The  final  ship,  EPD  28,  which  will  serve  as  a 
bridge  to  LX(R),  the  next  generation  of  Amphibious  Transport  Dock  ships,  was  recently 
authorized  by  Congress.  EPD  28  is  currently  planned  for  delivery  to  the  Navy  in  2022. 
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The  LPD  17  Class  Acquisition  Strategy  (AS)  called  for  the  use  of  a  Full  Service 
Contractor  to  be  the  whole-life  services  provider  to  the  Ship  Acquisition  Program 
Manager,  NAVSEA  PMS  317  (now  PEO  Ships,  PMS  317),  and  be  the  subcontractor  to 
the  shipbuilder,  formerly  named  Northrop  Grumman  Ship  Systems  (now  Huntington- 
Ingalls  Industries).  As  the  Mission  Systems  Integrator,  Raytheon  was  responsible  for 
implementing  a  new  ship  design  approach  known  as  Total  Ship  System  Integration 
(TSSI).  Through  this  approach,  Raytheon  produced  an  architecture  for  the  EPD  17  Class 
of  ships  that  integrated  23  Contractor  Eurnished  Equipment  (CEE)  systems  along  with  26 
Government  Eurnished  Equipment  (GEE)  systems. 

One  of  the  23  CEE  systems  designed  and  installed  on  the  EPD  17  Class  ships  by 
Raytheon  is  the  Shipboard  Wide  Area  Network  (SWAN).  The  concept  behind  the  SWAN 
was  to  design,  build,  test,  and  install  a  fully  integrated  shipboard  network  that 
incorporated  the  latest  in  commercially  available  information  technology. 

The  purpose  of  the  SWAN  is  to  provide  each  ship  with  more  than  1,000  data 
drops,  serve  as  the  fiber-optic  backbone  for  156  system-to-system  interfaces,  and  provide 
mission  critical  connectivity  in  support  of  shipboard  operations  and  warfighting.  The 
hardware  components  making  up  the  SWAN  are  enclosed  in  Raytheon-designed 
hardware  systems  that  meet  Military  Specification  MIE-S-901D  Grade  B  shock 
requirements.  The  SWAN  was  designed  to  grow  and  adapt  as  information  technology 
evolves.  To  this  point,  Raytheon  proposed  a  technology  refresh  plan  to  NAVSEA  with 
the  aim  of  maintaining  viability  for  the  SWAN  over  the  40-year  design-life  of  each  LPD 
17  Class  ship. 

Since  delivery  of  the  first  ship  in  the  LPD  17  Class  in  2006,  the  Navy  has  had  to 

invest  significant  capital  over  time  to  maintain  the  unique  SWAN  network,  to  train  sailors 

on  how  to  operate  it,  and  to  protect  against  emerging  Cyber  vulnerabilities.  Considering 

the  fact  that  there  are  284  ships  in  service  as  of  16Pebl5,  this  means  that  nine  of  those 

ships  have  the  unique  SWAN  network  installed,  requiring  dedicated  financial  and 

personnel  resources  tailored  to  the  SWAN.  Having  to  dedicate  resources  to  the  limited 

number  of  LPD  17  Class  ships  means  less  resources  available  to  support  the  rest  of  the 

ships  in  the  fleet  that  have  Government  Eurnished  Equipment  (GEE)  program  of  record 
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networks  installed.  The  mounting  Total  Ownership  Costs  (TOC)  associated  with  the 
SWAN  prompted  OPNAV  to  reconsider  the  future  of  the  SWAN  on  LPD  17  Class  ships 
(O’Rourke,  2011). 

In  March  2011,  the  Resource  Requirements  Review  Board  (R3B)  tasked  OPNAV 
N2/N6  and  N85  (now  N95)  to  assess  the  future  sustainment  of  the  LPD  17  Class  Network 
as  part  of  the  POM  14  process.  In  response  to  this  tasking,  OPNAV  N2/N6  and  N95 
jointly  authorized  PEO  C4I  (PMW  160)  and  PEO  Ships  (PMS  317)  to  lead  a  cross 
functional  study  team  for  the  purpose  of  providing  recommendations  for  LPD  17  Class 
Network  future. 

The  team  conducted  a  requirements  crosswalk,  a  method  of  mapping  the  functions 
of  one  system  to  another,  to  compare  the  network  requirements  of  the  LPD  17  Class 
(including  the  capabilities  of  the  LPD  17  Class  SWAN)  with  the  Consolidated  Afloat 
Network  Enterprise  System  (CANES),  the  Navy’s  new  Program  of  Record  (POR)  GEE 
shipboard  network  solution,  which  is  currently  being  fielded  in  the  Navy.  The  initial 
analysis  involved  the  development  and  evaluation  of  nine  Courses  of  Action  (COAs), 
which  were  eventually  reduced  to  three  COAs  regarding  the  future  for  sustainment  of  the 
EPD  17  Class  shipboard  network. 

Though  the  study  recommendation  was  endorsed  by  Navy  leadership,  a  huge 
challenge  remains  in  planning,  coordinating,  and  executing  the  replacement  of  the 
existing  SWAN  network  with  CANES. 

The  LPD  17  Class  SWAN  Sustainment  Study,  jointly  led  by  PEO  C4I  (PMW 
160)  and  PEO  Ships  (PMS  317)  in  December  2011,  recommended  that  the  C4I  Network 
portion  of  SWAN  be  replaced  with  CANES.  The  Assistant  Secretary  of  the  Navy  for 
Research  and  Development  (ASN  RDA)  accepted  the  recommendation  of  the  study  team 
and  authorized  OPNAV  to  resource  replacement  of  the  SWAN  on  the  EPD  17  Class  of 
ships  (CNO  OPNAV,  2011). 
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B,  PURPOSE 

The  Shipboard  Wide  Area  Network  (SWAN)  has  been  installed  on  the  10 
previous  ships  of  the  LPD  17  Class  and  is  eurrently  being  installed  on  LPD  27.  However, 
with  the  reeent  decision  by  Congress  to  authorize  funding  for  LPD  28,  the  Navy  has  the 
opportunity  to  implement  the  LPD  17  SWAN  Sustainment  study  recommendation  to 
install  CANES,  as  opposed  to  the  SWAN  during  New  Ship  Construction  on  LPD  28, 
which  presents  both  opportunity  and  risk  to  the  Navy. 

Ship  delivery,  a  New  Ship  Construction  term  synonymous  with  commissioning, 
for  LPD  28  is  currently  planned  for  May  2022.  Since  it  typically  takes  about  seven  years 
from  contract  award  to  ship  delivery  for  a  ship  of  the  LPD  17  Class,  the  Request  for 
Proposal  (RFP)  package,  which  must  include  enough  detailed  design  information 
allowing  the  shipbuilder  to  review  and  submit  a  bid  proposal,  is  expected  to  be  released 
to  the  shipbuilder  in  October  2015. 

Given  the  fact  that  the  LPD  17  Class  CANES  design  is  not  mature  at  this  time, 
providing  a  firm  Government  Furnished  Information  (GFI)  package  to  the  shipbuilder  in 
support  of  the  RFP  package  release  creates  a  dilemma  for  the  Department  of  the  Navy. 
The  dilemma  is  whether  to  provide  the  older,  mature  design  information  associated  with 
the  SWAN,  for  which  the  shipbuilder  has  experience  installing  vs.  providing  the 
immature  design  information  associated  with  CANES,  which  the  LPD  shipbuilder  has 
never  installed.  Since  CANES  will  go  through  at  least  one  hardware  refresh  cycle 
between  2017  and  2022,  the  importance  of  implementing  a  flexible  design  approach  is 
crucial  to  avoid  information  technology  obsolescence  issues  at  ship  delivery.  This 
situation  represents  a  challenge  that  has  faced  New  Ship  Construction  for  the  past  20 
years,  as  systems  complexity  and  technology  has  advanced.  The  fundamental  question 
today  is  “What  is  the  best  way  to  meet  the  shipbuilder  requirements  for  early  GFI,  while 
at  the  same  time,  allowing  for  advanced  information  technology  to  continue  to  mature  so 
that  the  ship,  when  completed  and  delivered  to  the  Navy,  will  have  the  latest  and  greatest 
in  shipboard  network  technology  installed?” 
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The  purpose  of  this  researeh  was  to  examine  the  reason  why  the  deeision  has  been 
made  to  replaee  the  C4I  Network  portion  of  SWAN  with  CANES,  to  closely  evaluate  the 
different  courses  of  action  considered  in  the  SWAN  Sustainment  Study,  to  analyze  the 
present  challenge  to  maintain  the  SWAN  Network  across  the  LPD  17  Ship  Class,  and  to 
examine  the  ongoing  effort  to  design,  develop,  test,  integrate,  produce,  install,  and  plan 
for  sustainment  of  the  LPD  17  Class  CANES  variant.  In  addition,  the  challenge  to  plan 
and  coordinate  the  replacement  of  SWAN  with  CANES  via  the  Navy  Modernization 
Process  was  examined.  Last,  the  thesis  includes  a  summary  of  key  points  made,  lessons 
learned  captured,  and  recommendations  for  implementing  the  study’s  recommended 
course  of  action,  including  a  potential  first  time  CANES  inline  installation  on  an  LPD  17 
Class  ship  during  New  Ship  Construction.. 

C.  RESEARCH  QUESTIONS 

The  effort  to  define,  design,  develop,  build,  integrate,  test,  produce,  and  install  a 
C4I  system  onboard  a  Navy  Ship  is  a  great  challenge  in  and  of  itself.  However,  the 
challenge  to  sustain  the  system  over  many  years  once  it  has  been  fielded  can  be  just  as 
daunting.  One  dilemma  facing  the  Department  of  the  Navy  at  present  is  whether  to  install 
an  unsustainable  CPE  network  onboard  a  New  Construction  Ship  while  the  design 
information  is  firm  for  Shipbuilding  purposes,  or  install  the  GEE  Program  of  Record 
solution,  while  the  design  information  is  still  under  development.  This  is  the  classic  New 
Ship  Construction  challenge  where  the  alignment  of  Government  Pumished  Information 
(GPI)  and  Government  Pumished  Equipment  (GEE)  milestones  supporting  New  Ship 
Constmction  and  C4I  system  design,  development,  procurement,  and  delivery  simply  don 
not  match  up  nicely.  The  basic  problem  is  that  the  shipbuilder  requires  firm  GPI  early  to 
support  detailed  design  for  Ship  Constmction,  whereas  the  C4I  system  may  still  be  in  the 
development  stage.  A  new  process  is  needed  that  will  meet  both  the  needs  of  the 
shipbuilder  and  the  Acquisition  Program  Office  fielding  the  C4I  System.  The  following 
questions  were  addressed  in  this  research  in  order  to  thoroughly  understand  the  challenge 
facing  the  Department  of  the  Navy  in  planning  for  the  installation  of  CANES  onboard 
LPD  28  during  New  Ship  Constmction: 
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1.  Why  has  the  decision  been  made  to  replace  the  C4I  network  portion  of 
SWAN  with  CANES  on  LPD  17  Class  ships? 

2.  How  should  the  recommendation  of  the  SWAN  Sustainment  Study  be 
implemented? 

3.  What  specifically  should  be  done  to  install  CANES  on  EPD  28  during  new 
construction  as  opposed  to  SWAN? 

D.  BENEFITS  OF  RESEARCH 

The  benefit  of  this  research  is  that  it  examined  the  current  processes  in  place  at 
the  shipbuilder  regarding  C4I  network  system  installation,  testing,  and  integration  and 
provides  improvement  recommendations  that  will  ultimately  lower  cost,  schedule,  and 
technical  performance  risk,  while  increasing  C4I  capability  at  Ship  Delivery. 

E.  SCOPE  AND  METHODOLOGY 

This  thesis  analyzed  the  challenge  of  avoiding  information  technology 
obsolescence  at  ship  delivery  when  designing,  procuring,  testing,  integrating,  delivering, 
and  installing  C4I  networks  during  New  Ship  Construction.  The  emphasis  was  on 
examining  shipbuilder  requirements  to  support  New  Ship  Construction,  while  balancing 
against  expected  changes  in  information  technology  associated  with  C4I  networks.  Close 
examination  of  this  very  challenge  was  done  for  EPD  28. 

F.  LITERATURE  REVIEW 

The  challenge  of  integrating  information  technology  systems  into  large,  complex 
projects  requiring  many  years  to  complete  necessitates  a  flexible  design  approach.  This  is 
true  whether  the  project  is  to  design  and  build  a  high-rise  office  complex,  a  jet  aircraft,  a 
warship,  or  a  spacecraft.  The  challenge  is  figuring  out  how  to  engineer  in  ways  during  the 
construction  process  that  will  accommodate  near  term  change  and  adaptability  for 
technological  improvements  throughout  the  life  cycle  of  the  project. 

The  focus  of  this  research  was  to  examine  the  best  method  of  replacing  an  older 
legacy  CEE  network  with  a  GEE  POR  solution  during  New  Ship  Construction  on  final 
EPD  17  Class  ship.  During  the  course  of  this  research,  a  literature  review  of  topics 
directly  related  to  the  Design  Budget  Process,  revealed  that  information  is  lacking.  (The 


7 


Design  Budget  Proeess  a  process  that  PEO  C4I  has  formally  instituted  and  linked  to  the 
Systems  Engineering  Technical  Review  (SETR)  process  in  support  of  New  Ship 
Construction  in  the  effort  to  minimize  the  risk  of  C4I  systems  obsolescence  at  ship 
delivery.)  However,  a  fair  amount  of  material  has  been  produced  on  similar  concepts, 
such  as  Pre-Planned  Product  Improvement  (P3I)  and  technology  insertion.  A  review  of 
literature  focused  on  P3I  and  technology  insertion  found  that  the  fundamental  challenge 
of  avoiding  information  technology  equipment  obsolescence  is  a  common  theme 
throughout  the  Department  of  Defense,  out  in  the  commercial  sector,  and  with  the 
individual  consumer. 

A  literature  review  was  also  conducted  on  the  SWAN  and  CANES.  Documents 
researched  included  the  LPD  17  Class  SWAN  Sustainment  Study  completed  in  201 1  and  a 
study  completed  by  the  RAND  National  Defense  Research  Institute  titled  CANES 
Contracting  Strategies  for  Full  Deployment.  These  documents  are  discussed  in  the 
following  sections. 
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II.  LPD  17  CLASS  SWAN  SUSTAINMENT  OVERVIEW 


A.  INTRODUCTION 

In  March  of  2011,  when  faced  with  a  $99M  Shipboard  Wide  Area  Network 
(SWAN)  sustainment  bill  across  the  FY13-17  Future  Years  Defense  Program  (FYDP) 
(PMS  317  POM  13  Issue  Paper),  the  Requirements  Review  Board  (R3B)  tasked  OPNAV 
N2/N6  and  OPNAV  N85  (now  N95)  to  conduct  a  study  of  the  LPD  17  Class  Shipboard 
Network  Architecture  and  provide  a  recommendation  for  the  future:  maintain  the  status 
quo  with  the  Commercially  Furnished  Equipment  (CFE)  SWAN  or  retrofit  the  existing 
11  LPD  17  Class  ships  with  the  new  Government  Eumished  Equipment  (GEE)  systems 
known  as  CANES. 

In  turn,  OPNAV  N2/N6  and  OPNAV  N85  jointly  authorized  the  Tactical 
Networks  Program  Office  (PMW  160)  within  PEO  C4I  and  the  LPD  17  Class  Ship 
Program  Office  (PMS  317)  within  PEO  Ships  to  lead  a  cross-functional  study  team  to 
assess  the  future  of  the  EPD  17  Shipboard  network. 

The  following  sections  provide  background  information  on  the  SWAN  network, 
CANES,  and  an  overview  of  the  SWAN  Sustainment  Study  analysis,  findings,  and 
recommendation. 

B,  BRIEF  OVERVIEW  OF  SWAN 

1,  SWAN  Description 

The  SWAN  is  a  subsystem  of  the  EPD  17  Class  Amphibious  Transport  Dock  Ship 
Integrated  Electronics  System.  The  SWAN  provides  for  transport,  network  management, 
system  management,  and  end  user  functions  and  services  for  intra-system 
communications  and  inter-system  communication  and  integration  onboard  LPD  17  Class 
ships. 

The  SWAN  is  composed  of  Ethernet  networking  elements,  plus  associated 
security  elements,  all  interconnected  via  the  network  fiber  optic  cable  plant.  It  provides 
the  physical  and  logical  connectivity  defined  by  the  baseline  EPD  17  Total  Ship 
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lufomiation  Management  (TSIM)  specification  and  supports  the  distribution  of  shipboard 
voice,  digital  video  and  digital  data  (Raytheon,  2007). 

2.  SWAN  “As  Is”  Architecture 

The  SWAN  is  ciuieutly  deployed  in  two  variants:  Gigabit  Mesh  and  Gigabit 
Ring.  Table  1  below  provides  a  smnmaiy  of  which  architechue  variants  are  installed  on 
each  of  the  LPD  17  Class  ships. 


Ship 

Network  Architecture  Type 

LPD  17-18 

Gigabit  Mesh 

LPD  19-21 

Gigabit  Ring 

LPD  22-25 

Gigabit  Mesh 

LPD  26-27 

Gigabit  Ring 

Table  1.  LPD  17  Class  Network  Configiuation  Type 

hi  the  Gigabit  Mesh  architecture,  as  depicted  in  Figme  1,  the  SWAN  core 
switches  are  connected  in  a  full  mesh  topology  where  each  node  captures  and  sends  its 
own  data  and  relays  the  data  on  to  other  nodes,  wliile  the  edge  switches,  routers,  seiwers, 
and  other  devices  are  connected  in  a  star'  topology,  where  one  central  hub  connects  the 
other  nodes  in  the  network  (Raytheon  2009). 


SWAN-  GigE  Mesh  Design 

(LPD  17,18,  22,  23,  24,  23) 


Figure  1 .  SWAN  GigE  Mesh  Design  (fiom  CNO  OPNAV  201 1) 
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In  the  Gigabit  Ring  architecture,  as  depicted  in  Figure  2,  the  SWAN  core  switches 
are  dual  connected  to  each  other,  while  the  router  and  servers  are  dual  connected  to  the 
core  switches.  Edge  switches  are  connected  in  a  ring  topology  (Raytheon  2009). 


SWAN  Server 
Dual  Homed  to  Core 


Figure  2.  SWAN  GigE  Ring  Design  (from  CNO  OPNAV  2011) 

The  SWAN  is  essentially  the  shipboard  network  infrastructure  onboard  LPD  17 
Class  ships  that  integrates  a  number  of  shipboard  electronic  systems.  These  systems 
include  the  Ship  Control  System  (SCS),  the  Navigation  Data  Distribution  System 
(NDDS),  the  Magnetic  Signature  Control  System  (MSCS),  the  Engineering  Control 
System  (ECS),  and  the  Command  Information  Display  System  (CIDS).  These  systems 
are  integrated  into  a  Common  Computing  Environment  (CCE)  for  EPD  17  Class  Ships, 
where  multiple  networks  were  replaced  with  one  complete  shipboard  network,  capable  of 
providing  all  the  physical  and  logical  connections  necessary  to  support  the  transport  of 
C4I,  FIM&E,  and  navigation  data,  and  allow  for  the  hosting  of  government  furnished 
software  applications,  such  as  Global  Command  and  Support  System  -  Maritime  (GCCS- 
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M),  Naval  Tactical  Command  Support  System  (NTCSS),  and  Common  PC  Operating 
System  Environment  (COMPOSE)  (Raytheon,  2007).  At  the  time  of  its  proposal  for 
installation  on  LPD  17,  the  SWAN  was  actually  a  transformational  and  revolutionary 
approach  for  shipboard  networks.  At  that  time,  all  government  furnished  shipboard 
networks  were  stove-piped,  meaning  that  the  networks  stood  alone  and  were  not 
integrated. 


Figure  3  depicts  the  current  functional  architecture  of  the  SWAN  onboard  LPD  17 
Class  ships. 


Figure  3.  SWAN  Functional  Architecture  (from  CNO  OPNAV  2011) 

C.  BRIEF  OVERVIEW  OF  CANES 
1,  CANES  Description 

The  Consolidated  Afloat  Networks  Enterprise  System  (CANES)  is  a  Program 
Executive  Office  (PEO)  Command,  Control,  Communications,  Computers,  and 

Intelligence  (C4I)  Program  of  Record  (POR)  system  that  is  currently  being  fielded  on 
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U.S.  Navy  ships.  CANES  serves  as  the  bridge  to  the  future  for  afloat  networks  onboard 
Navy  ships  and  is  fully  supported.  And,  like  the  SWAN,  CANES  consolidates  a  number 
of  existing  legacy  and  standalone  networks  onboard  Navy  ships.  CANES  provides  the 
necessary  shipboard  infrastructure  for  applications,  systems,  and  services  to  operate  in 
the  tactical  domain  and  delivers  its  capabilities  within  a  single  complete  system,  bringing 
the  necessary  hardware  onboard  ship  to  enable  the  timely  exchange  of  information  among 
tactical,  support,  and  administrative  users.  Figure  4  provides  a  logical  network  view  of 
CANES  across  the  Unclassified,  Secret,  Secret  Releasable/Coalition,  and  SCI  enclaves. 


CANES  is  a  mostly  a  commercial-off-the-shelf  (COTS)-based  system,  including 
hardware,  software,  storage  devices,  and  end  user  devices  operating  across  the  four 
enclaves  identified  in  Figure  4.  In  addition,  CANES  provides  for  the  hosting  of 
applications  that  support  C4ISR,  logistics,  and  business  domains. 
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The  CANES  Program  has  implemented  a  four-year  hardware  refresh  eyele  and  a 
two-year  software  refresh  cycle  in  the  effort  to  mitigate  obsolescence  issues  and  to 
provide  for  a  stable  and  predictable  configuration  and  modernization  roadmap.  CANES 
specifications  have  been  developed  to  promote  an  open,  modular,  and  scalable  design.  It 
is  anticipated  that  future  baselines  will  incorporate  new  advances  in  information 
technology  in  the  effort  to  expand  the  network  capabilities  delivered  to  the  fleet  with 
CANES  (PEG  C4I  2009). 

D,  SWAN  SUSTAINMENT  STUDY  OVERVIEW 

1.  Introduction 

The  initial  effort  of  the  SWAN  sustainment  analysis  involved  the  development 
and  analysis  of  nine  courses  of  action  (COAs),  which  were  eventually  reduced  three 
COAs  regarding  the  future  sustainment  of  the  SWAN.  The  SWAN  Sustainment  Study 
team  used  a  Balanced  Scorecard  Approach  to  provide  for  a  quantitative  analysis  of  the 
cost,  schedule,  benefits,  and  risks  of  each  COA.  The  COA  analysis  included  a  review  of 
the  costs  to  cover  the  necessary  engineering,  sustainment,  and  modernization  efforts  in 
support  of  a  Program  Objective  Memorandum  (POM)  submission  for  PY14  for  the 
recommended  COA  (CNO  OPNAV  2011). 

2,  COA  Overview 

The  study  team  first  examined  three  general  COAs  regarding  the  task  to  examine 
the  future  sustainment  of  the  LPD  17  Class  SWAN  network.  The  three  general  COAs 
included; 

•  COA  1  (Pull  SWAN  Model):  This  COA  was  basically  to  maintain  the 
status  quo,  where  NAVSEA  would  maintain  programmatic  responsibility 
for  the  SWAN  and  Raytheon  would  continue  on  as  the  In  Service 
Engineering  Agent  (ISEA)  for  the  CPE  Network. 

•  COA  2  (Pull  CANES  Model):  This  COA  considered  expanding  CANES, 
wherein  CANES  would  replace  SWAN  in  its  entirety. 

•  COA  3  (Pederated  Approach):  This  COA  considered  breaking  the  SWAN 
into  a  separate  HM&E  Network  and  then  having  CANES  take  over  the 
C4I  Network  portion  of  SWAN  only. 
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•  The  study  team  then  eompiled  the  requirements  of  both  the  SWAN  and 
CANES,  and  did  a  requirements  erosswalk  to  analyze  the  three  COAs 
listed  above.  As  a  result  of  the  requirements  erosswalk,  the  three  COAs 
were  expanded  to  the  following  nine  COAs: 

•  CO  A  1  A:  SWAN  Enclave  Hardware  Expansion 

•  COA  IB:  SWAN  +  CANES  (SR  and  SCI  Enclaves  only) 

•  COA  1C:  SWAN  Enclave  Hardware  and  Software  Expansion 

•  COA  ID:  Adopt  SWAN  plus  CANES  (SR  and  SCI  only)  as  a  PEO  C4I 

POR 

•  COA2A:  Pull  CANES 

•  COA  2B:  Pull  CANES  +  SWAN  Connected  Systems 

•  COA3A:  CANES  Pederated  w/ SWAN  (HM&E  only) 

•  COA  3B:  CANES  Pederated  w/  NSWC  HM&E  POR  Solution 

•  COA  4:  Modernize  SWAN  to  CANES  requirements 

The  study  team  then  used  a  Balanced  Scorecard  Approach,  which  is  a  standard 
method  of  objectively  scoring  multiple  options,  to  analyze  the  nine  COAs  listed  above 
and  selected  three  COAs  for  more  detailed  analysis.  The  three  COAs  chosen  were: 

•  COA  A:  SWAN  Enclave  Hardware  Expansion 

o  Expand/upgrade  the  SWAN  hardware  to  meet  CANES 
requirements 

o  Continue  with  the  integrated  C4I  and  HM&E  Network 

•  COA  B:  CANES  Pederated  with  NAVSEA  HM&E  POR  Network 

o  C4I  Network  portion  of  SWAN  replaced  by  CANES 

o  Navigation  Data  Distribution  System  (NDDS)  integrated  with 
HM&E  network 

o  NAVSEA  POR  HM&E  network  established  and  in  place  of 
SWAN  HM&E  network 

•  COA  C:  CANES  Pederated  with  NSWC  CD  HM&E  POR  Network 

o  C4I  Network  portion  of  SWAN  replaced  by  CANES 
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o  NDDS  provided  by  Raytheon  as  a  connected  system  to  the  NSWC 
CD  HM&E  Network 

o  NSWC  CD  FOR  HM&E  network  established  and  m  place  of 
SWAN  HM&E  network 

3.  CANES  /  SWAN  Capabilities  Comparison 

In  order  to  identify  the  impact  of  migr  ating  the  C4I  network  portion  of  the  SWAN 
on  the  LPD  17  Class  ships  to  CANES,  the  capabilities  of  the  SWAN,  and  all  C4I  network 
systems  cormected  to  the  SWAN,  had  to  be  identified  and  compared  against  the  projected 
capabilities  of  CANES  and  the  projected  CANES  connected  systems.  To  support  tliis 
comparison,  the  stirdy  team  built  a  comparison  matrix  and  condircted  a  requhements 
crosswalk  between  CANES  requirements  and  the  requirements  of  the  SWAN.  This 
requirements  crosswalk  was  itsed  to  determuie  where  capability  and  requhements  gaps 
existed  between  the  SWAN  and  CANES.  Table  2  surmnarizes  SWAN  capabilities  for  the 
LPD  17  Class  ships  and  CANES  capabilities  per  the  CANES  Fimctional  Specification 
(version  1.3.3)  as  they  apply  to  each  of  the  COAs  listed  above. 


Table  2.  SWAN/CANES  Capabilities  Comparison  to  COAs 

(fi-om  CNO  OPNAV  2011) 


Capability  (current) 

SWAN 

CANES 

COA  A 

COAB 

COAC 

Application  Hosting 

No 

Yes 

Included 

Included 

Included 

Enterprise  Software  Baseline 

Yes 

(COMPOSE) 

Yes 

(CANES) 

Included 

Included 

Included 

Compute  Resources  Infi'astructiu'e 
(Servers.  NW  Storage) 

Yes 

Yes 

Included 

Included 

Eicluded 

Computer  NW  Defense  Operating 
Sys  Ensiromiient  (CND-OSE) 

Coimected 

Yes 

Use  GEE  SW 

Included 

Included 

Cross  Domain  Solution 

Coimected 

Yes 

NRE  to 
proside 

Included 

Included 

Encryption 

Coimected 

Yes 

NRE  to 
provide 

Included 

Eicluded 

Enterprise  Network  System 

Management  (ENMS) 

Coimected 

Yes 

Use  GEE  SW 

Included 

Included 

External  Wireless  (Unclass) 

No 

Yes 

NRE  to 
provide 

Licluded 

Included 

Internal  System  Management 

Yes 

Yes 

Use  GEE  SW 

Included 

Included 

Internal  Wii'eless  (Secret) 

No 

Yes 

NRE  to 
provide 

Included 

Included 

Internal  Wii-eless  (Unclass) 

Yes 

Yes 

Included 

Included 

Included 
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Capability  (current) 

SWAN 

CANES 

COA  A 

COAB 

COAC 

NAV  Data  Distribution  (HDDS) 

Yes 

No 

Included 

UseCFE 

System 

Use  CFE 
System 

Net  Centric  Enterprise  Svcs 
(NCES)  -  Joint'AUied'Global  Info 
Grid  (GiG)/Coalition 

Interoperability 

Yes 

Yes 

Use  GFE  SW 

Inchrded 

Included 

Network  Transport 

Yes 

Yes 

Included 

Included 

Included 

NTP  Tinie  Distribution  (Stratum) 

Yes 

Yes 

Included 

Included 

Included 

Personal  Digital  Assistant  (PDA) 
Services 

No 

Yes 

NRE  to 
prostde 

Included 

Included 

Solaris  Operating  System  Support. 
Global  Command  and  Control 
System-Maritime  (GCCS-M) 

Hosting 

Yes 

Yes 

NRE  to 
provide 

HW  Included. 
Use  GFE  SW 

HW  Included. 
Use  GFE  SW 

Video  Distribution 

Cormected 

Yes 

NRE  to 
provide 

Included 

Included 

Video  Tele  Conference  (VTC) 

Cormected 

Yes 

NRE  to 
provide 

Included 

Included 

Voice  Over  IP  (VoIP) 

Secret/SR/SCI 

Cormected 

Yes 

Only  for  SCI- 
Provide  HW, 
Use  GFE  SW 

Included 

Included 

Definitions: 

Included-  Already  part  of  existing  baseline 

Use  GFE  SW  -  Requires  Govemment-Fumished  SW  (CANES  or  other  POR) 

NRE  to  proside  -  Requires  additional  Non  Recurring  Engineering  to  provide  capability 

Coimected  -  Not  part  of  Baseline;  fielded  as  independent  system  coimected  to  SWAN/CANES  transport 

Since  CANES  includes  the  fonner  stand-alone  C4I  legacy  networks  the  analysis 
by  the  shidy  team  also  had  to  include  those  C4I  systems  that  were  connected  to  the 
SWAN.  Table  3  provides  a  comparison  of  the  hosted  apphcations  and  connected  systems 
cimently  on  the  SWAN,  CANES,  and  included  with  each  of  the  three  COAs. 


Table  3.  SWAN/CANES  Hosted  &  Connected  Systems  Capability 
Comparison  (from  CNO  OPNAV  2011) 


Supported  S^'stems  (current) 

P.4KM 

SW.AN 

CAiNES 

C0.4  A 

COAB 

COA  C 

Afloat  Readiness  Reporting  System 
(ARRS) 

PMW  150 

Connected 

Hosted 

Hosted.  Use  GFE 
SW 

Hosted,  Use  GFE 
SW 

Hosted.  Use 
GFESW 

Automated  Digital  Network  System 
(ADNS)  Inter&ce 

PMli'lOO 

Connected 

Connected 

Connected 

Cormected 

Connected 

Combat  Systems  -  Cmd  Info  Dsply  Sys 
(CIDS)  or  Common  Visual  formation 
Sys  (CVIS) 

COA 

Dependent 

Connected 

Cormected 

Provided  by  Video  Distribution  (COA  Dependent) 

Combat  Systems  -  Cooperative 
Engagements  Capability  (CEC) 

PEOIWS 

Connected 

Connected 

Connected 

Connected 

Connected 

Combat  Systems  -  Sh^’s  Self  Defense 
System  (SSDS) 

PEOIWS 

Connected 

Connected 

Connected 

Connected 

Connected 
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Supported  Systeins  (current) 

FARM 

SWAN 

CANES 

COA  A 

COAB 

COAC 

Combined  Enterprise  Regional 
Information  Exchange  Sys-  Maritime 
(CENTRIXS-M) 

PMW  160 

COA  Dependent 

CANES 

Subsumes 

NRE  to  provide 
HW,UscGFESW 

CANES 

Subsumes 

CANES 

Subsumes 

US  Marine  Core  (USMC)  -  Servers  and 
Operatiug  System  SW 

MARFOR 

SYSCOM 

Connected 

Hosted 

Hosted.  Use  GFE 
SW 

Hosted.  Use  GFE 
SW 

Hosted.  Use 
GFESW 

Global  Command  and  Control  System- 
M  (GCCS-M) 

PMU'150 

Connected 

Hosted 

Hosted.  Use  GFE 
SW 

Hosted,  Use  GFE 
SW 

Hosted.  Use 
GFESW 

Hull  Mechanical  &  Elect  (HM&E)  - 
Fngr  Control  Sys  (ECS),  ^tegrat^ 
Condition  Assml  Sys  (ICAS) 

PMS470 

Connected 

Connected 

Connected 

Connected,  NRE 
to  segregate 
SWAN 

Connected. 
NRE  to 
develop 
HM&E 

Hull  Mechanical  &  Electrical  (HM&E)  - 
Damage  Control  Action  Management 
System  (DCAMS) 

COA 

Dependent 

Connected 

NA 

Coimected 

Connected,  NRE 
to  segregate 
SWAN 

Connected, 
NRE  to 
develop 
HM&E 

Hull  Mechanical  &  Electrical  (HM&E)  - 
Magnetic  Signature  Control  System 
(MSCS) 

Raytheon/ 

NSWC 

Connected 

NA 

Connected 

Connected,  NRE 
to  segregate 
SWAN 

Connected. 
NRE  to 
develop 
HM&E 

Hull  Mechanical  &  Electrical  (HM&E)  - 
Steering  Control  System  (SCS) 

COA 

Dependent 

Connected 

NA 

Connected 

Connected,  NRE 
to  segregate 
SWAN 

Connected. 
NRE  to 
develop 
HM&E 

NAV  Data  Distribution  (NDDS) 

Raytheon 

Connected 

NA 

Connected 

Connected, 
Hotels  for  NDDS 
as  HW,  NRE  to 
integrate 

Coimected, 
Hotels  for 
NDDS  as 
HW.NRE 
to  integrate 

Naval  Tactical  Command  Support 

System  (NTCSS) 

PMW  150 

Connected 

Hosted 

Hosted,  Use  GFE 
SW 

Hosted.  Use  GFE 
SW 

Hosted.  Use 
GFESW 

Navigation  Sensor  System  Inter&ce 
(NAVSSI) 

PMW  170 

Connected 

Connected 

Connected 

Connected 

Connected 

Navy  Information  Application  Product 
Suite  (NIAPS) 

PMW  240 

Connected 

Hosted 

Hosted,  Use  GFE 
SW 

Hosted.  Use  GFE 
SW 

Hosted.  Use 
GFESW 

Sensitive  Con^artmented  Information 
(SCI)  Network  Confuting  Infiastnicture 
or  Transport 

PMW' 160 

Independent 

PMW160POR 

CANES 

Subsumes 

NRE  to  provide 
HW.iiseGFESW 

CANES 

Subsumes 

CANES 

Subsumes 

Ship’s  Signal  Eiqtloitation  Equipment 
(SSEE) 

PMW  120 

Connected 

Tosa 

Connected 

Connected 

Connected 

Connected 

4.  Requirements  Crosswalk  Analysis 

Comparing  the  SWAN  and  CANES  requirements  provided  the  study  team  with 
great  insiglit  into  the  fimctions  accomplished  by  the  SWAN  and  CANES,  as  well  as  the 
perfoimance  parameters  to  which  each  system  is  validated.  The  requirements  were 
segregated  into  two  major  categories: 

•  CANES  requirement  statements  not  met  by  SWAN  requuements 

•  SWAN  reqiruement  statements  not  met  by  CANES  requirements 
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There  are  1,562  CANES  requirements  (PEO  C4I  2009)  and  there  are  482  SWAN 
requirements  (Raytheon  2009).  Figure  5  shows  how  the  SWAN  and  CANES 
requirements  map  to  eaeh  other. 


1562  CANES  ReQuirements 


^82  SWAN  ReQuirerrents 


■  141  Tti'eslrolc  Rems 
AppIcaOlelo  SWftNIforCOAA 


627  AppteaSte  CANES 
RqmS  fuly  met  Met  by 
SWAN 


t88  CA7£S  RqmS  Met 
by  SWAN  Mlh  CANES 
GFESWonSWAN  HW 

90  Appbcable  CANES 
RqmS  paliNly  Mel  by 
SWAN 


391  SVWJ  or  Sererc  LPD  Syssem 
Rqmls  AppUableto  CANES 


257SWAN-only 
AppIcableRqmtsMet 
by  CANES 


61  Genenc  LPO  System 
RqiT«s  MetbyCANES 


73NbSirnlar 
Rqinis  m  CANES? 


NOTES: 

1) Connpanson  isbeMeen  SWAN  and  CANES  REQUIREMENTS:  actual  SWAN/CANEScapabilites  depend  on  mnpiementation 

2)  905  CANES  RqmtsMap  to  318  SWAN  Rqmts  ;ie..  Multiple  CANES  RqmtsMap  fc  one  SWAN  Rqmt) 

3)  LPD  17  Class  mdudes  LPD  17-27  (te.  11  Hulls) 

Figure  5.  SWAN/CANES  Requirements  crosswalk 
(from  CNO  OPNAV  2011) 

The  requirements  mapping  in  Figure  5  shows  that  905  CANES  requirements  map 
to  318  SWAN  requirements,  which  means  that  there  are  cases  where  multiple  CANES 
requirements  map  to  one  SWAN  requirement.  Here  are  four  key  takeaways  from  the 
SWAN/CANES  Requirements  crosswalk  completed  by  the  study  team; 

•  236  CANES  requirements  are  not  met  by  the  SWAN 

•  421  CANES  requirements  are  not  applicable  to  the  LPD  17  Class  ships 

•  73  SWAN  requirements  have  no  similar  CANES  requirement 

•  91  SWAN  requirements  are  not  applicable  to  CANES 

5.  COA  Analysis 

The  LPD  17  Class  SWAN  Sustainment  Study  team  used  the  Delphi  method  to 
evaluate  each  COA  (CNO  OPNAV,  2011).  In  using  this  approach,  shipboard  network 
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subject  matter  experts  (SMEs)  were  identified  and  involved  in  both  the  development  of 
specific  selection  criteria  and  the  voting  process.  To  score  each  of  the  CO  As,  the 
Balanced  Scorecard  Approach,  which  is  a  quantitative  method  of  evaluating  alternatives 
based  on  a  variety  of  defined  criteria,  was  used  to  determine  which  COA  provided  the 
best  value  to  the  Navy.  The  following  criteria  were  used  to  select  the  best  COA; 

•  Total  Ownership  Cost  (TOC) 

•  Development  schedule 

•  Required  modernization  AVAIL  window 

•  Ability  to  leverage  existing  sustainment  &  support  infrastructure 

•  Risk 

•  Impact  to  training  pipeline  /  Integrated  Logistical  Support  (ILS) 

•  Technical  interoperability 

Over  the  course  of  three  In  Process  Review  (IPR)  periods,  data  was  collected  and 
analyzed  for  each  of  the  three  COAs.  The  study  team  evaluated  each  of  the  COAs  against 
the  established  criteria  and  scored  them  using  the  Balanced  Scorecard  approach.  Table  4 
shows  the  definitions  for  the  scoring  criteria  used  by  the  study  team  to  evaluate  the 
COAs. 
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Criterion 

Yellow:  3 

Green:  5  1 

< 

ce. 

Total  Ownership  Cost 
(TOC) 

roc  (FY14  -  27)  >  S600M 

roc  (FY14  -  27)  <=  $600M 

roc  (FY14-27)  <=$500M 

lij 

q: 

Schedule 

COA  Development  Schedule 
>24  months 

COA  Development  Schedule 
<=  24  months 

30A  Development  Schedule  <= 
18  months 

LU 

> 

Modernization 

Required  Availability  >  5 
months 

Required  Availability  <=  5 
months 

Required  Availability  <=  3 
months 

1- 

z 

< 

n 

O 

Sustainment  /  ISEA 

■  Class-Specific  Help  Desk 
•  Class-Specific  ISEA  Team 
and  practices 

■  Leverages  common  Help 

Desk  with  fleet 
•  Class-Specific  ISEA  Team 
and  practices 

Leverages  common  Help  Desk 
with  fleet 

■  Common  ISEA  Team  and 
practices  across  multiple 
alatforms 

Risk 

Overall  COAAverage  Risk 
Score  >15 

Overall  COAAverage  Risk 
Score  <15 

Dverall  COAAverage  Risk  Score 
<8 

< 

a. 

UJ 

1- 

Di 

O 

m 

> 

TralnIng/ILS 

Significant  impact  to  training 
Dlpeline: 

■  Requires  development  of  new 
training  packages  independent 
of  PEO  C4I  PoR  training 
packages 

■  No  commonality  with  PEO 

C4I  Baseline 

Some  impact  to  training 
pipeline: 

■  Requires  modification  of 
axisting  PEO  C4I  PoR  training 
packages 

■  Leverages  common 
components  from  PEO  C4I 

PoR  Baseline 

y/linimal  impact  to  training 
pipeline: 

No  additional  training  packages 
equired 

Common  with  PEO  C4I  PoR 
Saseline 

< 

3 

a 

Technical 

Interoperability 

■  Technical  COAAverage  Risk 
Score  >15 

■  Dedicated  SIT  outside  current 
PEO  C4I  PoR 

■  Technical  COAAverage  Risk 
Score  <15 

■  Dedicated  SIT  outside  current 
PEO  C4I  PoR 

Technical  COAAverage  Risk 
Score  <  8 

Delta  SIT  from  existing  PEO 

D4I  PoR  solution 

Table  4.  LPD  17  Study  team  Balanced  Scorecard  Criteria  Definition  Table 

(from  CNO  OPNAV  2011) 

To  highlight  one  example  of  the  study  team’s  efforts  to  collect  data  and  conduct 
analysis,  Table  5  shows  a  summary  of  the  TOC  for  each  of  the  three  COAs.  As  Table  4 
shows,  COA  B  has  the  lowest  cost  to  implement  across  the  FYDP  at  $169.7M  and  the 
lowest  TOC  from  FY14  to  FY27  at  $412.7M. 


COA  A 

FY14 

FY15 

FY16 

FYU 

FY18 

FYDP  Total 

TOC  (FYU -271 

RDT&E 

S 

6.989.62 

S 

S 

1.801,36 

S 

S 

6,989,62 

S  15.780.59 

S 

33.36255 

OPN 

s 

68.540.08 

S  93.624.30 

S 

59,354.26 

S 

12,54211 

S 

17.135.02 

S  251.195.76 

S 

679.000.56 

OMN 

s 

4.005.24 

S  9.601.11 

s 

9,313.73 

s 

6,228.42 

s 

3.286.79 

S  32435.28 

s 

84.90279 

COA  A  Total 

$ 

79,534.93 

$  103,225.41 

$ 

70.469.35 

$ 

18,770.52 

$ 

27,411.42 

$  299,411.64 

$ 

797,266  90 

COAB 

FYU 

FY15 

FY16 

FYU 

FY18 

FYDP  Total 

TOC  (FYU -271 

RDT&E 

s 

2.137.00 

S 

S 

333.45 

S 

S 

979.58 

S  3.450.04 

S 

6.076.11 

OPN 

s 

35.183.88 

S  50,300.00 

s 

33,377.74 

s 

8,243.72 

s 

8.493.08 

S  135.598.42 

s 

331.583.94 

OldN 

s 

3.324.21 

S  5,797.08 

s 

6,443.69 

s 

8,041.18 

s 

7,029.61 

S  30.635.77 

s 

75.02839 

COA  B  Total 

$ 

40,64510 

$  56,097.07 

$ 

40.154.88 

$ 

16.28489 

$ 

16,502,27 

$  169.684.22 

$ 

412,68543 

COAC 

FYU 

FY15 

FY16 

FYU 

FY18 

FYDP  Total 

TOC  (FYU -27) 

RDT&E 

s 

3.270.11 

S 

S 

338,62 

s 

S 

614.47 

S  4.223.20 

S 

6.129.38 

OPN 

s 

39.860.35 

S  58,798.23 

s 

39,531.91 

s 

10,13280 

s 

9.633,16 

S  157.956,45 

s 

350.729,04 

OWN 

s 

4.330.60 

S  6,492.36 

s 

7,149.00 

s 

8,946.02 

s 

8,093.50 

S  35.011.48 

s 

86.635.46 

COAC  Total 

$ 

47,461.06 

$  65,290.59 

$ 

47,019.54 

$ 

19,07581 

$ 

15341,12 

$  197,191,13 

$ 

443,49587 

Table  5.  COA  Total  Ownership  Cost  (TOC)  Summary 
(from  CNO  OPNAV  2011) 
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E. 


SWAN  SUSTAINMENT  STUDY  RECOMMENDATION 


Based  on  analysis  of  each  COAs  cost,  assessed  risk,  and  the  other  selection 
criteria,  the  LPD  17  Network  Study  team  recommended  COA  B,  the  Federated  Network 
approach  with  CANES  as  the  C4I  Network  and  a  NAVSEA  FOR  established  for  the 
HM&E  Network.  COA  B  was  evaluated  as  having  the  lowest  TOC  and  risk.  In  addition, 
COA  B  was  considered  to  be  more  technically  feasible  and  best  aligned  with  current 
Navy  PORs.  Table  5  shows  the  Balanced  Scorecard  results  from  the  study  team’s 
evaluation  of  the  three  COAs. 


Criterion 


COAB 


Total 

Ownership  Cost 
(TOC) 

Schedule 


COA  Development  Schedule; 
15  Months 

Required  Availability: 

3  months 


Risk 


Overall  COA  Average  Risk 
Score :  9.7 


Technical 

Interoperability 


TOC  (FY14  -  27);  S413M 


COA  Development  Schedule: 
15  months 

Required  Availability: 

3  months 

-Leverages  Existing  PEO  C4I 
-Help  Desk  and  ISEA  Practices 
-ISEA  team  spread  across 
multiple  platforms 


Overall  COA  Average  Risk  Score  : 
4.9 


Some  impact  to  training  pipeline: 

-  Requires  modification  of  existing 
PEO  C4I  POR  training  packages 

-  Leverages  common  components 

from  PEO  C4I  POR  Baseline 


-Tech  Risk  Score:  10 
■  Dedicated  SIT  outside  cunent 
PEO  C4I  POR 


-  Tech  Risk  Score:  N/A 
-  Delta  SIT  from  existing  PEO  C4I 
POR  solution 


COAC 


TOC  (FY14  -  27);  $443M 


COA  Development  Schedule: 
15  months 

Required  Availability: 

3  months 

-Leverages  Existing  PEO  C4I 
-Help  Desk  and  ISEA  Practices 
-ISEA  team  spread  across 
multiple  platforms 


Overall  COA  Average  Risk  Score  ; 
5.6 


Some  impact  to  training  pipeline: 

-  Requires  modification  of  existing 
PEO  C4I  POR  training  packages 

-  Leverages  common  components 

from  PEO  C4I  POR  Baseline 


-  Tech  Risk  Score:  N/A 
-  Delta  SIT  from  existing  PEO  C4I 
POR  solution 


Table  6.  LPD  17  Network  Study  team  Balanced  Scorecard  Results 

(from  CNO  OPNNAV  2011) 

F.  CHAPTER  SUMMARY 

In  March  2011,  OPNAV  was  presented  with  a  significant  cost  of  $99M  to  sustain 
the  SWAN  from  FYI3  to  FYI7  on  1 1  LPD  17  Class  ships.  In  today’s  resource 
constrained  environment,  the  Department  of  the  Navy  leadership  decided  to  consider 
other  alternatives  in  the  effort  to  mitigate  this  cost.  And,  as  a  result,  the  LPD  17  Network 
Study  team  was  created  to  consider  COAs  for  the  LPD  17  Class  shipboard  network  and 
to  provide  a  recommendation  for  implementation. 
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Over  the  eourse  of  nine  months  from  March  2011  to  December  2011,  the  LPD  17 
Network  Study  team  identified  nine  potential  COAs,  determined  the  three  best  COAs, 
collected  extensive  data  supporting  each  COA,  and  conducted  detailed  analysis  on  the 
three  COAs.  Three  In  Process  Reviews  (IPRs)  were  held  reporting  on  the  evaluation  of 
the  progress  on  COA  to  OPNAV  and  Navy  Leadership. 

Using  the  Balanced  Scorecard  approach  to  evaluate  the  COAs,  the  study  team 
determined  that  the  best  alternative  would  be  to  federate  the  SWAN  Network  on  LPD  17 
Class  ships  by  replacing  the  C4I  Network  portion  of  SWAN  with  CANES  and  by 
replacing  the  HM&E  Network  portion  of  SWAN  with  a  new  POR  HM&E  Network  to  be 
established  at  NAVSEA.  This  approach  was  evaluated  as  being  the  most  cost  effective 
for  the  long  term,  having  the  least  amount  of  risk,  and  as  having  the  lowest  impact  to  the 
Navy  as  a  whole  to  implement  with  respect  to  training,  ILS,  and  existing  In  Service 
Engineering  Agent  (ISEA)  support. 

In  January  2012,  the  LPD  17  Network  Study  was  officially  delivered  to  OPNAV 
N85  (now  N95),  OPNAV  N2/N6,  and  ASN  (RDA)  (the  Assistant  Secretary  of  the  Navy 
for  Research,  Development,  and  Acquisition).  The  study  recommendation  was  accepted 
and  approved  for  implementation.  With  approval  granted,  POM  issue  papers  were 
submitted  to  OPNAV  in  support  of  POM  14  by  the  CANES  Program  from  the  Tactical 
Networks  Program  Office  from  PEO  C41  (PMW  160)  requesting  funding  to  develop  an 
LPD  17  Class  variant  of  CANES  and  to  procure  CANES  Production  Units  for  fielding  on 
the  In  Service  LPD  17  Class  ships  during  AVAIL  windows  spanning  PY14  -  PY18. 

Unfortunately,  the  government  shutdown  and  the  subsequent  impact  of 
sequestration  put  a  two-year  delay  in  the  LPD  17  CANES  development  and  fielding 
effort.  So,  good  momentum  from  the  study  team’s  effort  was  lost.  However,  the 
development  effort  is  now  back  on  track,  with  the  EPD  17  CANES  variant  design 
expected  to  be  completed  by  July  2015,  and  the  first  LPD  17  Class  CANES 
Modernization  AVAIE  install  planned  to  start  in  October  2016  on  LPD  18  (NEW 
ORLEANS). 
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The  challenge  now  facing  the  Department  of  the  Navy  is  whether  to  modify  the 
existing  LPD  17  shipbuilding  contract,  by  including  CANES  in  the  Request  For  Proposal 
(REP)  scheduled  to  be  released  to  the  shipbuilder  in  October  2015.  If  the  decision  is  made 
to  install  CANES  during  New  Ship  Construction,  it  will  be  in  line  with  the  LPD  17 
Network  Study  recommendation.  However,  it  will  be  a  change  to  the  Shipbuilding 
Contract,  which  will  impact  the  shipbuilder.  On  the  other  hand,  if  the  decision  is  made  to 
stay  with  the  SWAN  on  LPD  28,  the  Navy  faces  the  old  dilemma  of  a  New  Construction 
Ship  delivering  to  the  Navy  in  the  2022  -  2023  timeframe  with  an  outdated  information 
technology  system  installed  that  must  immediately  be  removed  and  replaced  with  a  newer 
system  during  the  first  Modernization  AVAIL  window,  which  is  a  great  waste  of  the 
taxpayer’s  money.  The  reminder  of  this  research  will  focus  on  the  effort  to  align  the  LPD 
17  CANES  variant  design  and  development  effort  to  the  LPD  28  New  Ship  Construction 
effort. 
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III.  DESIGNING,  INTEGRATING,  AND  TESTING  CANES 


A.  INTRODUCTION 

The  fielding  of  new  C4I  systems  onboard  U.S.  Navy  warships  is  a  complex  effort 
requiring  close  coordination  between  many  entities  operating  within  the  DOD  5000 
Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management 
System,  which  is  comprised  of  the  Joint  Capabilities  Integration  and  Development 
System  (JCIDS),  the  Defense  Acquisition  System,  and  the  Planning,  Programming, 
Budgeting,  and  Execution  Process  (PPBE  Process).  As  stated  in  DOD  Directive  5000.1, 
“The  Defense  Acquisition  System  exists  to  manage  the  nation’s  investments  in 
technologies,  programs,  and  product  support  necessary  to  achieve  the  National  Security 
Strategy  and  support  the  United  States  Armed  Eorces.  The  investment  strategy  of  the 
Department  of  Defense  shall  be  postured  to  support  not  only  today’s  force,  but  also  the 
next  force,  and  future  forces  beyond  that.  The  primary  objective  of  Defense  Acquisition 
is  to  acquire  products  that  satisfy  user  needs  with  measurable  improvements  to  mission 
capability  and  operational  support,  in  a  timely  manner,  and  at  a  fair  and  reasonable 
price.” 

One  such  C4I  system  currently  being  fielded  onboard  Navy  ships  with  the 
objective  of  satisfying  warfighter  needs  with  measurable  capability  improvements  is 
CANES,  which  is  an  Acquisition  Category  (ACAT)  lA  Major  Automated  Information 
System  (MAIS)  Program  managed  by  Program  Executive  Office,  Command,  Control, 
Communications,  Computers,  and  Intelligence  (PEO  C4I).  The  CANES  initiative  was 
developed  in  collaboration  with  the  Naval  EORCEnet  Enterprise  (NNEE)  as  a  framework 
to  fundamentally  enhance  C4ISR  capabilities  in  the  Elect.  As  stated  in  the  CANES 
Acquisition  Strategy,  the  four  primary  goals  of  CANES  include  the  following; 

•  Provide  a  secure  afloat  network  for  Naval  and  Joint  Operations. 

•  Consolidate  and  reduce  the  number  of  afloat  networks  through  the  use  of 
Common  Computing  Environment  (CCE)  and  mature  cross  domain 
technologies. 
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•  Reduce  the  infrastructure  footprint  and  associated  Logistics,  Sustainment, 
and  Training  costs. 

•  Increase  reliability,  security,  interoperability,  and  application  hosting  to 
meet  current  and  projected  warfighter  requirements. 

Fundamentally,  CANES  is  an  effort  focused  on  consolidating  all  C4I  afloat 
networks  into  a  single  network  that  provides  Navy  ships  with  a  Common  Computing 
Environment  (CCE),  Cross  Domain  Solutions  (CDS),  and  delivers  a  foundation  for 
achieving  a  Services  Oriented  Architecture  (SOA)  by  providing  a  common  set  of  tailored 
Afloat  Core  Services  (ACS). 

Today,  there  are  four  primary  shipboard  C4I  networks  on  U.S.  Navy  ships:  the 
NIPRNET  (the  Unclassified  Network),  the  SIPRNET  (the  Classified  Network),  the 
Sensitive  Compartmented  Information  (SCI)  Network,  and  the  Combined  Enterprise 
Regional  Information  Exchange  System  (CENTRIXS),  each  operating  at  different 
security  levels.  Additionally,  there  are  a  number  of  non  POR  systems  that  support  video 
data  exchange  and  distribution  onboard  ship,  such  as  the  Video  Information  Exchange 
System  (VIXS)  and  Ships  Video  Distribution  Systems  (SVDS).  The  results  of  a  survey 
conducted  by  the  Tactical  Networks  Program  Office  within  PEO  C4I  in  2010  revealed 
the  extent  of  network  variance  regarding  the  status  of  legacy  shipboard  networks: 

•  642  legacy  systems  on  300+  Navy  platforms 

•  162  Integrated  Shipboard  Networking  System  (ISNS)  systems  (17+ 
variants) 

•  151  CENTRIXS  systems  (four  variants) 

•  144  SCI  Networks  systems  (ten  variants) 

•  50  Submarine  Local  Area  Network  (SubLAN)  systems  (eight  variants) 

•  102  VIXS  systems  (five  variants) 

Given  the  proliferation  of  CEE  Networks,  such  as  the  SWAN  on  LPD  17  Class 
ships  and  the  TSCE  on  the  Littoral  Combat  Ship  (LCS),  one  can  readily  see  that  the  great 
number  of  disparate  C4I  networks  presents  a  significant  challenge  to  the  Navy  with 
respect  to  life  cycle  sustainment,  cyber  security,  and  the  training  of  Navy  sailors. 
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OPNAV  saw  this  as  a  major  problem  and  determined  that  the  status  quo  was  not 
sustainable.  In  addition,  OPNAV  was  eoncerned  that  the  older  legacy  networks  did  not 
support  rapid  technology  insertion  and/or  capability  expansion.  Additionally,  it  was 
determined  that  the  shipboard  network  infrastructure  did  not  support  the  Navy’s  way 
ahead  for  Net-centric  Warfare  or  for  interfacing  with  the  Global  Information  Grid  (GIG). 
The  OPNAV  review  revealed  a  number  of  capability  gaps  in  four  primary  areas:  (a) 
System  Interoperability  and  Responsiveness;  (b)  Collaboration;  (c)  Information  Access  & 
Exchange;  (d)  Cross-Domain  Solutions  (CANES  CDD).  PEO  C4I  was  funded  by 
OPNAV  to  initiate  a  program  to  address  the  four  primary  capability  gaps  identified 
above,  regarding  shipboard  networks.  The  CANES  Program  was  established  in  2008  to 
satisfy  these  capability  gaps  and  to  develop  a  solution  to  meet  the  warfighter’s  shipboard 
network  capability  needs  and  eliminate  the  great  degree  of  network  variance  existing  on 
Navy  afloat  platforms. 

After  a  successful  Gate  6  Review  conducted  in  December  of  2012,  CANES 
received  Milestone  C  approval  in  Eebruary  of  2013  and  entered  the  Eimited  Deployment 
Eielding  Phase  of  the  Program.  CANES  is  currently  in  the  Eull  Deployment  phase  of  the 
program,  with  installations  either  completed  and/or  in  progress  on  20  ships  as  of  March 
2015.  However,  no  CANES  installations  have  been  completed  as  yet  for  any  of  the  EPD 
17  Class  ships.  EPD  28  would  be  the  first  opportunity  for  the  Navy  to  make  the  decision 
to  replace  a  major  CPE  shipboard  C4I  network  with  a  GEE  POR  solution  during  New 
Ship  Construction.  In  light  of  the  great  number  of  disparate  C4I  networks  already  in 
service  on  U.S.  Navy  ships,  serious  consideration  must  be  granted  to  installing  CANES 
on  EPD  28  during  New  Ship  Construction  in  the  attempt  to  eliminate  variance,  reduce 
total  life  cycle  sustainment  costs,  and  increase  protection  against  cyber  threats. 

B,  CAPABILITY  NEED  DETERMINATION 

The  JCIDS  Process  involves  an  analysis  of  Doctrine,  Organization,  Training, 

Material,  Eeadership,  Education,  Personnel,  and  Pacilities  (DOTMEPP)  in  an  integrated, 

collaborative  process  to  define  gaps  in  warfighting  capabilities  and  propose  solutions 

(Joint  Chiefs  of  Staff  2015).  As  stated  in  the  previous  section,  OPNAV  conducted  a 

review  of  shipboard  network  capabilities  out  in  the  Elect  in  the  2008  timeframe  and 
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identified  four  major  C4I  network  capability  gaps.  OPNAV’s  gap  analysis  led  to  the 
creation  of  the  CANES  Program  to  address  the  identified  gaps  in  capability. 

The  end  state  goal  of  CANES  is  to  provide  a  single  C4I  network  infrastructure 
onboard  Navy  ships  that  leverages  Multi-Level  Security  (MLS)  and  Afloat  Core  Services 
(ACS)  architectures.  Table  7  lists  the  capabilities  that  CANES  is  to  provide  to  Navy 
Afloat  units  (PEO  C4I,  2009). 


CANES  System  Capabilities 

Voice 

IP  Telephony 

*  To  include  mobile  and  stationary  end  points;  secure  and  unsecure  communications 

Video 

Video  Teleconferencing 

*  To  include  point-to-point  and  point-to-multi-point 

Video/ Graphics  Distribution 

*  To  include  video  broadcast  distribution  and  data  wall/large  screen  display  capabilities 

Data  Services 

Network  Support 

*  To  include  Common  Network  Services;  Network  Identity  Lifecycle  Management;  Network  Access  Management 

Information  Management 

*  To  include  Application  Hosting,  Server  Based  Databases;  Print  Services;  Peripheral  Devices;  Email  &  Calendar 
Services;  Office  Productivity  &  Automation;  Messaging  Tools;  Collaboration  Tools;  Knowledge  Management;  Core 
Infrastructure 

Core  Infrastructure  Services 

*To  include  Data  Mediation;  Metadata  &  Metadata  Discovery;  Service  Orchestration;  Service  Discovery;  People 
Discovery;  Content  Discovery;  Device  Discovery;  Middleware;  Federated  Search 

Network  Access  (All  IP  &  IPv4/IPve  Capable) 

*  To  include  CANES  and  non-CANES  interfaces 

Information  Delivery 

*  To  include  data  transport  infrastructure  in  support  of  Expanded  Maritime  Interception 

System  Management  Services 

Performance,  Availability,  and  Service  Level  Management 

*  To  include  performance,  availability,  &  Service  Level  Agreement  (SLA)  monitoring;  QoS; 

Fault,  Problem,  Incident,  and  Service  Desk  Management 

*  To  include  automated  handling  of  system  faults  and/orfailures;  help  desk  management; 

Configuration,  Change,  and  Release  Management 

*  To  include  automatic  establishment  of  system  baseline;  automatic  maintenance  of  system 

Security  Management 

*  To  include  security  incident  prevention/reduction;  security  incident  detection;  security  incident 

Capacity  Management 

*  To  include  monitoring  and  management  of  system  usage;  recording  and  reporting  of  system 

Table  7.  CANES  System  Capabilities  (from  PEO  C4I  2009) 


In  addition  to  providing  the  capabilities  identified  in  Table  7,  as  previously 
mentioned,  an  OPNAV  review  identified  a  number  of  specific  network  capability  gaps 
that  CANES  was  to  address.  Table  8  identifies  six  specific  capability  gaps  that  CANES  is 
required  to  address  (PEO  C4I  2009). 
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Capability  Gaps  to  Be  Addressed  by  CANES 

System 

Interoperability 

Systems  unable  to  fully  support  interoperability  and  security  for  operation  in  a  distributed  environment  (GIG  MA ICD);  failure  to  use  open 
standards  and  Net-Ready  interfaces  to  permit  cross  domain  flow  of  information;  integration  and  interoperability  of  existing  and  future  systems 
(GIG  ES  ICD);  The  operational  community  needs  solutions  to  support  the  sharing  of  information  within  DoD  as  well  as  with  interagency,  and 
authorized  allied,  coalition,  and  multinational  partners  as  appropriate  (Warfighter  CONORS);  minimal  vertical/  horizontal  information  exchange 
and  coordination  among  the  National  Military  Command  System  (NMCS),  Combatant  Command  (COCOM)/Service/Agency,  Intelligence 

Community  (1C),  Homeland  Security/Homeland  Defense,  and  multi-national  components.  (Net-Enabled  Command  Capability  (NECC)  CDD) 

Collaboration 

Teams  cannot  consistently  and  effectively  interact  in  real  time  (GIG  MA  ICD);  difficulty  finding  data  or  inability  to  use  once  found  due  to  a  lack  of 
common  understanding  of  what  data  means  (GIG  ES  ICD);  when  users  can  access  needed  data,  they  may  find  the  data  unusable  due  to  a  lack  of 
understanding  of  what  the  data  means  or  the  structure  of  the  data;  lack  of  relevancy  due  to  time  lag  (Warfighter  CONORS);  current  systems 
do  not  provide  adequate  integrated  collaborative  capabilities  to  support  vertical/horizontal  C2  information  exchange/coordination  among  the 
NECC  Community.  (NECC  CDD) 

Information 

Access 

Existing  systems  focused  at  the  Service  level;  users  are  unaware  that  needed  data  already  exists;  publication  of  and  subscription  to  required 
information  is  available  only  at  the  local  level  (GIG  MA  ICD);  information  exchange  in  response  to  events  or  requests  is  not  available;  rapidly 
indexed/cataloged,  distributed,  stored,  searchable,  and  retrievable  information  is  not  available;  information  is  not  uniformly  tagged  (GIG  ES  ICD); 
Users  and  producers  of  information  cannot  rapidly  index,  catalog,  store,  search,  and  retrieve  required  information  (Warfighter  CONORS);  web- 
based  capabilities  to  access/search,  generate,  post,  or  advertise  mission-relevant  information  are  not  sufficient;  insufficient  ability  to  retrieve, 
broker,  translate,  aggregate,  fuse,  or  integrate  information  (NECC  CDD) 

Cross-Domain 

Security 

Users  are  unable  to  access  data  due  to  security,  technical  challenges,  or  organizational  boundaries;  information  exchange  problems  with  our 
authorized  allied  and  coalition  partners  (GIG  MA  ICD);  incapable  of  cross-domain  security  supported  from  a  user  desktop;  inability  to  rapidly  tailor 
access  to  GIG  ES  information  and  services  for  Non-DoD  users;  secure  exchange  of  information  between  differing  security  domains  is  unavailable 
(GIG  Information  Assurance  (lA)  ICD,  GIG  ES  ICD);  Operational  security  considerations  have  a  direct  impact  on  a  command's  dissemination  policy, 
which  will  limit  access  (Warfighter  CONORS);  exchange  of  data  of  various  classifications  across  multiple  security  domains  (UNCLAS  through  TS  and 
SCI)  via  a  secure  infrastructure  is  unavailable;  lack  of  broad  access  to  national  imagery/intelligence  databases  and  integration  of  theater-produced 
intelligence.  (GIG  lA  ICD,  NECC  CDD) 

Information 

Exchange 

Minimal  capability  to  process  multiple  languages  of  both  spoken  language  and  applications;  inability  to  capture  cultural  context  in  which  humans 
function;  heavy  reliance  on  text  message  formats  and  inability  to  process  multimedia  presentations  (GIG  MA  ICD);  marginal  ability  to  provide  to 
relevant  DoD,  non-DoD,  authorized  allies/coalition  partners  survival  information  and  updates;  lacking  ability  to  associate  information  or  data 
element  security  classification  levels,  releasability,  and  Special  Handling  Caveats;  mediation  of  multiple  spoken  and  computer-based  languages; 
advanced  information  exchange,  e.g.,  web-based  messaging  (GIG  ES  ICD);  minimal  capability  to  process  multiple  languages  of  both  spoken 
language  and  applications  limits  the  effective  presentation  of  information;  this  situation  is  particularly  constraining  in  allied  and  coalition 
operations  (Warfighter  CONORS);  NCES  must  be  compatible  with  allied  users  on  the  Secret  Internet  Rrotocol  Router  Network  (SIPRNET)  and 
available  to  allied  users  entering  the  SIPRNET  via  mechanisms  such  as  Globally  Reaching  Interactive  Fully  Functional  Information  Network 
(GRIFFIN) 

System 

Responsiveness 

Increased  demands  for  data  storage  capacity,  transmission  speeds,  and  information  availability;  operational  fragmentation  and  segregation  of 
information;  data  flow  across  systems  and  domains;  unacceptably  slow  access  to  pull  or  push  data  even  when  user  has  mission  priority  (GIG  MA 
ICD);  information  processing  is  optimized  at  Service,  COI,  or  local  level  and  does  not  maximize  capacity,  decrease  redundancy,  or  increase 
interoperability  (GIG  ES  ICD);  Operational  fragmentation  and  segregation  of  information  by  type,  classification,  command,  and  mission  make  it 
difficult  to  transport,  store,  and  process  essential  information  (Warfighter  CONORS);  does  not  provide  the  capability  to  forward  local  intelligence 
and  analysis  into  national  databases.  (NECC  CDD) 

Table  8.  Capability  Gaps  Addressed  by  CANES  (from  PEO  C41 2009) 

CANES  was  developed  to  provide  the  warfighter  with  the  eapabilities  listed  in 
Table  7  and  to  address  the  eapability  gaps  identified  in  Table  8.  Warfighter  user 
requirements  are  addressed  in  the  CANES  CDD  as  Key  Performance  Parameters  (KPPs) 
and  Key  System  Attributes  (KSAs)  that  are  required  to  support  the  system  capabilities  to 
be  delivered  by  CANES.  KPPs  are  the  system  parameters  considered  most  essential  to 
the  warfighter  and  the  KSAs  are  parameters  that  support  developing  the  optimal 
engineering  solution  to  deliver  the  desired  capability.  As  with  all  DOD  acquisition 
programs,  threshold  and  objective  values  are  established  for  each  KPP  and  KSA  in  the 
CDD. 
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1. 


CANES  KPPs 


Key  Performance  Parameters  (KPPs)  are  those  attributes  or  performance 
characteristics  considered  most  essential  for  an  effective  military  capability.  The  KPPs 
capture  the  minimum  operational  effectiveness  and  suitability  attributes  needed  to 
achieve  the  overall  desired  capabilities  of  the  related  system  designed  to  deliver  the 
capabilities.  The  CDD  states  the  operational  and  support  related  performance  attributes  of 
the  system  being  developed  to  provide  the  capabilities  required  by  the  warfighter.  All 
KPPs  contain  an  initial  value  that  can  be  verified  by  testing  or  other  analysis  (Joint  Chiefs 
of  Staff  2015).  Table  9  contains  a  listing  of  the  CANES  KPPs. 

As  a  CEE  Network,  the  SWAN  did  not  have  to  go  through  the  DOD  5000 
Acquisition  rigor  required  of  CANES.  And,  as  a  result,  the  argument  can  be  made  that  the 
SWAN,  and  other  CEE  networks  such  as  the  TSCE,  were  never  designed  to  fully  meet 
warfighter  capability  requirements  in  terms  of  Systems  Availability,  Material 
Availability,  and  the  Net-Ready  KPP  required  of  all  information  technology  systems. 
This  is  an  item  that  must  be  considered  by  Navy  leadership  when  considering  selecting 
CEE  C4I  systems  for  installation  on  New  Construction  ships  in  the  future. 
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KPP# 


1 


2 


Capability 


System 

Availability 


Initial 

Critical  services  >=  0.99 

Non-Critical  services  >=  0.95 _ 

Critical  user  access  devices  >=  0.99 


CCJO  Characteristics 

Enduring  /  Persistent; 
Resilient 


Mate  rial 
Availability 


Non-Critical  user  access  devices  >=  0.85 
Critical  services  >=  0.95 

Non-Critical  services  >=  0.90 _ 

Critical  user  access  devices  >=  0.95 
Non-Critical  user  access  devices  >=  0.80 
CANES  shall  fully  support  execution  of 
Joint  critical  operational  activities 
identified  in  the  applicable  Joint  and 
system  integrated  architectures  and 
the  system  must  satisfy  the  technical 
requirements  fortransition  to  Net- 
Centric  military  operations  to  include 
the  following: 


Enduring/Pe  rsiste  nt; 
Resilient 


Networked;  Interoperable; 
Expeditionary;  Adaptable  / 
Tailorable;  Enduring/ 
Persistent;  Precise;  Fast; 
Resilient;  Agile 


1)  DISR  mandated  GIG  IT  standards  and 

profiles  identified  in  the  TV-1 _ 

2)  DISR  mandated  GIG  KIPs  identified 

in  the  KIP  declaration  table _ 

Net-Ready  3)  NCOW-RM  Enterprise  Services _ 

KPP  4)  lA  requirements,  including 

availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation, 
and  issuance  of  an  Interim  Approval  to 
Operate  (lATO)  by  the  Designated 
Approval  Authority  (DAA) 

5)  Operationally  effective  information 
exchanges  and  mission  critical 
performance  and  lA  attributes,  data 
correctness,  data  availability,  and 
consistent  data  processing  specified  in 
the  applicable  Joint  and  system 
integrated  architecture  views 


Table  9.  CANES  Key  Performanee  Parameters  (KPPs) 

(from  PEG  C4I  2009) 

To  highlight  this  point  further,  one  major  performanee  problem  with  the  SWAN  is 
its  inability  to  guarantee  a  minimum  level  of  Quality  of  Serviee  (QoS)  for  an  array  of 
applieations.  The  fundamental  issue  is  that  the  SWAN  does  not  have  a  formal 
requirement  for  QoS  at  the  applieation  layer  (Riposo  2012).  Basieally,  the  SWAN  has  a 
high-speed  baekbone  network  with  edge  switehes  that  eonneet  other  networks,  whieh 
have  applieations  loaded  on  servers.  The  SWAN  does  have  a  QoS  requirement  for  the 
baekbone  network.  However,  there  are  no  QoS  speeifieations  for  the  edge  networks, 
whieh  are  not  part  of  the  core  network  (Riposo  2012). 
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What  this  means  is  that  for  the  networks  connected  to  the  edge  switches,  the  data 
service  is  basically  on  a  first-come,  first-served  basis.  This  works  fine  during  periods  of 
low  data  traffic.  However,  when  there  is  a  requirement  to  distribute  data  requiring  high 
bandwidth,  such  as  for  video  or  high  resolution  imagery,  the  data  packets  will  start  to  be 
dropped  by  the  system.  Clearly,  this  is  a  major  impact  to  the  warfighter. 

One  of  the  critical  lessons  learned  from  the  SWAN  design  approach  is  that  QoS 
must  extend  all  the  way  to  the  applications  loaded  on  the  networks  connected  to  the  edge 
devices.  How  did  this  happen?  The  original  specifications  for  the  SWAN  were  at  the 
ship  specification  level,  which  is  too  high.  Since  the  SWAN  was  a  CFE  approach 
managed  by  the  Electronic  Systems  Integrator,  industry  was  given  the  task  of  applying 
the  requirements  to  the  lower  levels,  with  no  process  in  place  for  the  government  to 
dictate  QoS  requirements  (Riposo  2012).  Eooking  ahead  to  CANES,  QoS  is  a 
requirement  called  for  in  the  CDD  that  must  be  satisfied  (PEO  C4I  2009). 

2.  CANES  KSAs 

Key  System  Attributes  (KSAs)  are  system  characteristics  that  are  considered 
essential  to  achieving  a  balanced  solution,  but  not  critical  enough  to  be  designated  a  KPP. 
Eike  KPPs,  KSAs  must  be  measurable,  testable,  and  quantifiable  (Joint  Chiefs  of  Staff 
2015).  Table  10  is  a  listing  of  the  CANES  KSAs. 
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Table  10.  CANES  Key  System  Attributes  (KSAs)  (from  PEO  C4I  2009) 

Seetion  6.2  of  the  CANES  CDD  contains  detailed  information  that  defines  each 
KSA  in  output  oriented,  measurable,  and  testable  terms.  In  addition,  the  CDD  lays  out 
development  threshold  and  objective  values  for  each  KSA.  The  basic  premise  behind  the 
CANES  KSAs  is  that  they  were  used  to  incentivize  the  CANES  contractor  to  add 
additional  enhancements  and  capability  during  the  development  phase  of  CANES  in  the 
effort  to  develop  an  optimal  product  that  meets  the  warfighter  needs  and  capabilities. 
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c. 


CANES  Platform  Sets 


The  CANES  acquisition  and  development  strategy  is  centered  on  what  is  known 
as  Platform  Sets.  A  Platform  Set  (PS)  is  basically  a  set  of  CANES  variant  designs 
organized  by  group.  Eor  instance,  Platform  Set  1,  includes  the  CANES  design  for  a  DDG 
5 1  Class  Destroyer,  which  was  the  first  CANES  variant  to  be  produced,  tested  in  the  lab, 
and  installed  onboard  a  Navy  ship.  Table  10  below  provides  a  summary  of  the  CANES 
Platform  Sets. 


Platform  Set  1  Platform  Set  3 


DDG  -  Guided  Missile  Destroyer 


Platform  Set  2 


CG  -  Guided  Missile  Cruiser 

CVN  -  Carrier  Vessei  Nuclear  (Multi-Purpose 

Nuclear  Aircraft) 

LCC  -  Landing  Ship  Control  (Amphibious 
Command  Ship) 

LHA  -  Landing  Helicopter,  Amphibious  (General 
Purpose  Amphibious  Assault  Ship) 

LHD/LHA-7  -  Landing  Helicopter  Dock  (Multi¬ 
purpose  Amphibious  Assault  Ship) 

LSD  -  Landing  Ship,  Dock 

MOC  -  Maritime  Operations  Center 

TIE  -  Technical  Training  Equipment 


BCA  -  Broadcast  Control  Authority 
SSBN  -  Submersible  Ship  Ballistic  Missile 
Nuclear 

SSGN  -  Submersible  Ship  Guided  Missile 
Nuclear 

SSN  21  -  Submersible  Ship  Nuclear  (Nuclear- 
Powered  Seawolf  Class) 

SSN  688  -  Submersible  Ship  Nuclear  (Nuclear- 
Powered  Los  Angeles  Class) 

SSN  774  -  Submersible  Ship  Nuclear  (Nuclear- 
Powered  Virginia  Class) 

SUBOPAUTH  -  Submarine  Operating  Authority 


Platform  Set  4 


AS  -  Submarine  Tender 

JHSV  -  Joint  High  Speed  Vessel 

LCS  -  Littoral  Combat  Ship 

LPD  -  Amphibious  Transport  Dock 

LPD-17  -Amphibious  Transport  Dock 


Table  1 1 .  CANES  Platform  Sets  (from  PEO  C4I  2009) 

Please  note  that  the  LPD  CANES  variant  falls  under  Platform  Set  4,  which  was 
under  development  at  the  time  this  research  was  being  conducted.  Section  E  of  this 
chapter  will  provide  an  overview  of  the  CANES  Systems  Engineering  Process  and  how  it 
is  being  used  to  develop  the  LPD  CANES  variant,  the  first  ship  set  of  Platform  Set  4. 

D.  CANES  TECHNICAL  BASELINE  DEVELOPMENT 

As  discussed  previously  in  the  Capability  Need  Determination  section  of  this 
research,  the  CANES  capabilities,  KPPs,  and  KSAs  have  been  established  and 
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documented.  Looking  to  the  future,  the  CANES  Program  intends  to  offer  enhaneements 
to  the  eapabilities  eurrently  available  and  add  new  eapabilities  driven  by  warfighter  needs 
(CANES  CDD).  The  speeific  eapabilities  now  offered  by  CANES  are  identified  in  the 
Operational  Availability  (Ao),  Material  Availability  (MA),  and  Net  Ready  KPPs 
identified  in  Table  9. 

A  deeomposition  of  the  CANES  eapabilities,  as  defined  in  the  CDD,  was 
eompleted  and  is  published  in  the  CANES  Architeeture  Specifieation  (AS).  The  goal  of 
the  CANES  AS  is  to  translate  the  CANES  CDD  capabilities  and  System  Views  (SV)  into 
an  initial  set  of  functional  and  non-functional  requirements  such  that  they  ean  be  traced 
baek  to  the  user  needs  (PEO  C4I,  2010).  Figure  6  shows  the  linkage  of  the  CANES 
eapabilities  and  how  they  are  translated  into  suecessive  engineering,  funetional,  alloeated, 
and  finally  the  produet  baseline. 

Considering  that  the  CANES  CDD  defines  the  eapabilities  that  CANES  is 
required  to  deliver  to  the  warfighter  and  that  the  KPPs  establish  metries  for  determining 
how  well  CANES  is  performing  as  a  system  in  delivering  the  defined  eapabilities.  Figure 
7  shows  how  the  CDD  drives  the  Arehiteeture  Speeifieation  (AS),  whieh  in  turn, 
translates  the  user-defined  eapabilities  expressed  in  the  CDD  into  speeifie  engineering 
requirements  from  whieh  a  series  of  CANES  system  development  baselines  ean  be 
iteratively  developed  (PEO  C4I,  2009). 

As  the  system  development  proeess  eontinues  from  the  Functional  Baseline 
through  sueeessive  engineering  iterations,  the  solution  spaee  grows  narrower  and 
narrower  until  an  optimal  system  design  is  determined.  The  funetional  arehiteeture  and 
eorrelated  requirements  expressed  in  the  Funetional  Speeifieation  serve  as  the  origin  and 
impetus  for  the  physieal  design  at  the  Alloeated  and  subsequent  baselines. 
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Figure  6.  CANES  CDD  Relationship  to  Product  Specifications  and 

Baselines  (from  PEO  C4I  2009) 

E.  CANES  SYSTEMS  ENGINEERING  APPROACH 

As  depicted  in  Figure  7,  the  CANES  Systems  Engineering  Team  followed  the 
Systems  Engineering  “V”  Model  to  develop  CANES.  This  model,  first  formally 
described  by  Kevin  Eorsberg  and  Harold  Mooz,  starts  with  the  user  needs  on  the  upper 
left  and  ends  with  a  user-defined  system  on  the  upper  right.  On  the  left  side, 
decomposition  and  definition  activities  resolve  the  system  architecture,  creating  details  of 
the  design.  Integration  and  verification  flows  up  and  to  the  right,  as  successively  higher 
levels  of  subsystems  are  verified.  Verification  and  validation  progresses  from  the 
component  level  to  the  validation  of  the  entire  operational  system.  At  each  level  of 
testing,  the  originating  specifications  and  requirements  documents  are  consulted  to  ensure 
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that  the  components,  subsystems,  and  system  meet  all  specifications  (Blanchard  and 
Fabrycky  2006) 

Using  the  Systems  Engineering  “V”  Model  proved  highly  effective  in  translating 
the  warfighter  capability  requirements  laid  out  in  the  CANES  CDD  into  an  end  product 
that  was  testable  against  those  requirements.  The  following  sections  provide  an  overview 
of  process. 
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Figure  7.  CANES  Systems  Engineering  “V”  Model  (from  PEO  C4I  2010) 


1,  Requirements  Development 

Requirements  Development  was  the  first  challenge  faced  by  the  CANES  SE 
Team.  It  was  during  this  phase  that  the  CANES  SE  Team  used  information  from  the 
CANES  CDD,  KPPs,  KSAs,  DODAE  Operational  Views  (OVs),  program  constraints, 
and  Test  &  Evaluation  Master  Plan  (TEMP)  to  develop  system  requirements,  use  cases, 
system  validation  threads,  and  architecture  specifications  (PEO  C4I  2010).  A  Systems 
Requirements  Review  (SRR)  was  conducted  and  the  approved  output  of  the 
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Requirements  Development  Phase  was  a  validated  CANES  Engineering  Development 
Model  (EDM).  An  overview  of  the  Requirements  Development  phase  is  depieted  in 
Figure  8. 


CDD.  KPPs,  KSAs,  DoDAF  OVs, 
Program  Constraints.  TEMP 


;VA,  SVR 


CANES  Architecture 
Specifications 


Establish  Engineering  Baseline  and  Begin 
Building  Functional  Architecture  Model 


Program  Planning  Updates 


Figure  8.  CANES  Requirements  Development  (from  PEO  C4I  2010) 


2,  Functional  Analysis 

The  next  challenge  was  to  take  the  Engineering  Baseline  (EBL)  produced  during 
Requirements  Development  and  to  conduct  Functional  Analysis.  During  this  phase  the 
CANES  SE  Team  developed  functional  requirements,  functional  specifications,  sequence 
diagrams,  a  functional  structure  model,  system  verification  threads,  and  established 
Configuration  Control  of  the  baseline,  and  developed  a  Requirements  Traceability  Matrix 
(RTM).  A  Systems  Functional  Review  (SFR)  was  conducted  and  the  approved  output  of 
the  Functional  Analysis  Phase  was  a  Functional  Baseline  (EBL)  (PEO  C4I  2010).  An 
overview  of  the  Functional  Analysis  phase  is  depicted  in  Figure  9. 
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Figure  9.  CANES  Functional  Analysis  (from  PEO  C4I  2010) 


3,  Preliminary  Design 

Following  Functional  Analysis,  the  CANES  SE  Team  next  entered  the 
Preliminary  Design  Phase  of  the  SE  Process.  During  this  phase  the  CANES  SE  Team 
developed  the  CANES  physical  architecture,  allocated  requirements  to  subsystems, 
developed  sequence  diagrams,  developed  subsystem  verification  threads,  and  updated  the 
RTM.  A  Preliminary  Design  Review  (PDR)  was  conducted  and  the  approved  output  of 
the  Preliminary  Design  Phase  was  an  Allocated  Baseline  (ABE),  which  included 
subsystem  specifications  for  CANES  subsystems,  such  as  racks,  storage  devices,  and 
software  packages  (PEO  C4I  2010).  An  overview  of  the  Preliminary  Design  Phase  is 
depicted  in  Figure  10. 
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Figure  10.  CANES  Preliminary  Design  (from  PEO  C41  2010) 

4,  Detailed  Design 

Eollowing  Preliminary  Design,  the  CANES  SE  Team  next  entered  the  Detailed 
Design  Phase  of  the  SE  Proeess.  During  detailed  design,  the  CANES  SE  Team  seleeted 
eomponents  to  implement  the  physical  architecture,  finalized  the  composition  of 
hardware  and  software,  and  developed  a  detailed  design  for  each  unique  Platform  Set.  A 
Critical  Design  Review  (CDR)  was  conducted  and  the  approved  output  of  the  Detailed 
Design  Phase  was  a  Design  Baseline  (DBE),  which  included  component  level 
specifications  and  detailed  design  information  (PEO  C41  2010).  An  overview  of  the 
Detailed  Design  Phase  is  depicted  in  Eigure  1 1 . 


40 


C20ta 


Figure  1 1 .  CANES  Detailed  Design  (from  PEO  C4I  2010) 


5,  Implementation  and  Beyond 

Following  Detailed  Design,  the  CANES  SE  Team  next  entered  the 
Implementation  Phase  of  the  SE  Proeess.  This  is  the  start  of  the  effort  to  build,  test,  and 
integrate  the  CANES  Engineering  Development  Model  (EDM),  better  known  as  the  “Test 
Set.”  In  this  phase  the  CANES  SE  Team  went  on  to  establish  the  framework  for 
completing  the  remaining  phases  of  the  SE  Process — Component  Verification, 
Subsystem  Verification,  and  System  Validation  (PEO  C4I  2010).  Figure  12  shows  the 
various  Contract  Data  Requirements  Lists  (CDRLs)  that  the  CANES  SE  Team  used  for 
Implementation. 
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Figure  12.  CANES  Implementation  (from  PEO  C4I  2010) 


With  the  Implementation  Phase  eompleted,  the  CANES  SE  Team  worked  with  the 
Contractor  to  build  an  EDM  and  conducted  component,  subsystem,  and  system 
verification  testing.  Along  each  step  of  the  way,  testing  was  completed  to  ensure  that  the 
requirements  established  during  the  Design  Phase  (the  left  hand  side  of  the  SE  V)  were 
being  met  by  the  system  designed.  The  horizontal  lines  labeled  “Test  Requirements” 
represent  the  linkage  between  requirements  and  verification  /  validation.  Subsystem 
Integration  and  Verification  testing  was  done  to  develop  Technical  Data  Packages 
(TDPs)  for  the  CANES  subsystems.  Then,  System  Verification  testing  was  done  to 
develop  a  TDP  for  the  CANES  system  as  a  whole. 

Closing  out  the  SE  V,  an  lOT&E  was  successfully  completed  on  a  CANES 
system  installed  on  a  ship  in  January  2015.  The  lOT&E  event  was  used  to  validate  that 
the  system  worked  properly  and  satisfied  all  requirements  set  forth  in  the  CDD.  With  a 
successful  lOT&E  completed,  authority  was  granted  by  the  Milestone  Decision  Authority 
(MDA)  for  the  CANES  Program  to  proceed  to  the  Pull  Deployment  Phase  of  fielding. 
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Figure  14  on  the  following  page  shows  the  CANES  development  cycle  from  Capability 
Need  to  Installation  and  Sustainment  onboard  ship. 
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Figure  13.  CANES  Development  Fife  Cycle  (from  PEO  C4I  2009) 

As  Figure  13  shows,  the  ultimate  goal  of  the  CANES  Program  Office  effort  is  to 
get  CANES  installed  onboard  U.S.  Navy  ships.  And,  in  order  to  install  CANES,  five 
fundamental  items  are  required:  (1)  CANES  hardware,  (2)  software,  (3)  Installation 
Requirements  Drawings  (IRDs),  (4)  Ship  Installation  Drawings  (SIDs),  and  (5)  the 
Configuration  Item  Control  Drawing  (CICD).  The  hardware  listing,  software  listing,  and 
IRDs  are  products  of  the  SE  Process,  where  the  hardware  and  software  is  included  in  the 
Bill  of  Materials  (BOM)  for  CANES  and  the  IRD  is  the  CANES  design  on  paper  for  the 
given  ship  variant.  The  Ship  Installation  Drawing  Package  is  a  set  of  drawings  that 
describe  how  to  install  CANES  hardware  onboard  a  ship.  The  CICD  includes  detailed 
instructions  on  how  to  load  the  software  on  CANES.  The  objective  of  the  CANES  SE 
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Team  is  to  develop  and  maintain  Configuration  Control  of  the  CANES  BOM,  IRDs,  and 
CICD  for  eaeh  CANES  variant  design  via  the  Systems  Engineering  Proeess. 

As  of  Mareh  2015,  CANES  has  been  installed  on  the  following  classes  of  U.S. 
Navy  ships:  DDG  51  Class,  CG  47  Class,  LSD  41/49  Class,  CVN  68  Class,  CVN  78 
Class,  LHD  1  Class,  and  LHA  6  Class.  Per  Table  11  on  page  35,  this  covers  Platform 
Sets  1  and  2.  However,  CANES  has  not  been  installed  on  any  of  the  ship  classes  that  fall 
on  Platform  Sets  3  or  4  (The  LPD  17  Class  CANES  effort  falls  under  Platform  Set  4  and 
is  currently  in  development).  In  addition,  no  New  Construction  Ship  has  yet  to  deliver  to 
the  Navy  with  CANES  installed,  as  all  CANES  installations  have  occurred  on  In  Service 
ships  via  the  Navy  Modernization  Process  during  CNO  AVAILS.  So,  in  and  of  itself,  the 
installation  of  CANES  during  New  Ship  Construction  presents  a  unique  challenge. 

One  of  the  key  tenets  of  the  CANES  design  approach  is  scalability.  Therefore,  a 
significant  amount  of  commonality  exists  from  one  ship  class  CANES  design  to  another. 
However,  each  CANES  design  is  tailored  to  the  unique  requirements  and  capability  needs 
of  a  given  ship  class.  The  effort  to  develop  the  LPD  17  Class  CANES  variant  builds  on 
the  Systems  Engineering  work  previously  completed  in  building  the  other  CANES 
variants.  So,  the  same  SE  Process  model  approach  laid  out  in  sections  1-5  of  this  chapter 
still  applies  for  the  LPD  17  Class  CANES  development  effort. 

The  biggest  challenge  facing  the  CANES  SE  Team  with  respect  to  developing  the 
LPD  17  Class  CANES  design  is  ensuring  that  all  core  functions  previously  performed  by 
the  C4I  Network  portion  of  the  SWAN  will  be  captured  in  the  new  LPD  17  Class 
CANES  variant  design.  This  is  very  important  because  with  the  LPD  17  CANES  effort 
represents  the  first  time  in  which  a  GEE  Network  on  any  U.S.  Navy  ship  will  replace  an 
existing  CEE  Network.  So,  one  crucial  goal  is  that  when  all  is  said  and  done,  the  C4I 
network  capabilities  that  were  in  place  prior  to  the  CANES  install  will  still  be  in  place 
(and  hopefully  enhanced)  after  the  CANES  installation  is  completed. 

Keeping  in  mind  that  LPDs  17-27  all  had  the  SWAN  installed  inline  by  the 
shipbuilder  during  New  Ship  Construction,  any  attempts  to  install  CANES  inline  on  LPD 
28  will  carry  unique  Cost,  Schedule,  and  Technical  Performance  risks.  For,  if  the 
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Department  of  the  Navy  deeides  to  press  ahead  and  install  CANES  on  LPD  28  during 
New  Ship  Construction,  it  would  be  the  first  time  that  the  shipbuilder  will  be  installing 
CANES  on  an  LPD  17  Class  ship.  The  ability  of  the  shipbuilder  to  install  the  SWAN  on 
LPDs  is  firm  and  stable,  for  the  shipbuilder  has  a  firm  design  and  experience.  This  is  not 
the  case  with  CANES.  So,  there  is  a  bit  of  inherent  risk  at  stake  here. 

The  unique  challenge  facing  the  Department  of  the  Navy  for  LPD  28  is  that  a 
Request  for  Proposal  (REP)  supporting  the  award  of  the  Shipbuilding  Contract  will  be 
released  in  October  of  2015.  And,  the  REP  must  include  a  Technical  Data  Package 
(TDP),  which  will  provide  enough  detail  regarding  construction  requirements,  systems  to 
install,  etc.,  for  the  shipbuilder  to  review  and  provide  a  bid  to  build  the  ship.  So,  in 
preparation  to  release  the  REP,  a  decision  has  to  be  made  as  to  whether  to  install  SWAN 
during  New  Ship  Construction,  which  the  shipbuilder  has  successfully  done  in  the  case 
with  all  previous  LPDs,  or  change  direction  and  install  CANES  inline,  which  is  immature 
in  design  and  will  be  new  to  the  shipbuilder.  In  short,  the  Navy  is  facing  the  decision 
whether  to  install  an  older,  legacy  shipboard  network,  which  will  have  to  be  replaced  at 
great  cost  after  LPD  28  delivers  to  the  Navy,  or  install  the  latest  shipboard  network  inline 
during  New  Ship  Construction. 

F.  CHAPTER  SUMMARY 

The  Systems  Engineering  Approach  to  solving  complex  problems  entails  three 
fundamental  steps:  (1)  define  the  problem  in  the  form  of  requirements  captured  in 
specifications;  (2)  creatively  synthesize  the  requirements  into  design  solutions  believe  to 
satisfy  those  requirements,  and  (3)  prove  through  testing  and  other  methods  that  the 
resultant  product  does  in  fact  satisfy  the  requirements,  thereby,  solving  the  original 
problem  (Grady  1998). 

The  CANES  SE  Team  used  the  Systems  Engineering  Approach  to  solve  the 
complex  problem  of  designing,  testing,  and  integrated  a  C4I  network  for  installation 
onboard  U.S.  Navy  ships.  The  problem  to  be  solved  was  defined  in  the  requirements, 
KPPs,  and  KSAs,  as  laid  out  in  the  CANES  CDD.  Then,  the  CANES  SE  Team 
synthesized  those  requirements  into  design  solutions  represented  by  the  EBL,  FBL,  ABE, 
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and  finally,  the  DBL.  And,  finally,  the  CANES  SE  Team  proved  that  the  design 
developed  satisfied  the  original  problem  through  verifieation  testing  on  an  Engineering 
Developmental  Model  (EDM)  in  the  lab  and  then  validated  that  the  original  requirements 
were  met  by  condueting  an  lOT&E  event  at  sea  on  a  CANES  system  installed  onboard  a 
ship. 

There  are  three  widely  aeeepted  Systems  Engineering  Proeess  Models:  (1)  the 
Waterfall  Model,  (2)  the  Spiral  Development  Model,  and  (3)  the  “V”  Development 
Model  (Blanchard  and  Fabrycky  2006).  The  CANES  Systems  Engineering  Team  chose  to 
use  the  Systems  Engineering  V  Development  Model  to  design,  build,  test,  and  integrate 
CANES.  From  the  establishment  of  the  Capability  Need  and  well  defined  requirements, 
as  laid  out  in  the  CANES  CDD,  to  the  validation  of  the  CANES  system  installed  onboard 
ship  at  sea  during  lOT&E,  the  SE  V  Process  Model  proved  highly  effective  for  the 
CANES  Program. 
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IV.  DESIGN  BUDGET  OVERVIEW 


A.  INTRODUCTION 

In  a  perfect  world,  mature  and  stable  Government  Furnished  Information  (GFI) 
for  C4I  and  information  technology  systems  would  be  available  to  support  the 
shipbuilder’s  detailed  design  and  construction  effort  at  the  shipbuilding  contract  award 
date.  However,  as  previously  discussed  in  the  Introduction,  C4I  and  information 
technology  equipment  is  forever  rapidly  changing  due  to  Moore’s  Law.  For  this  reason, 
obsolescence  risk  is  an  ever-present  concern  in  the  world  of  shipbuilding. 

This  point  is  well  communicated  in  a  study  conducted  by  the  Rand  Corporation 
(2011)  titled  Are  Ships  Different!  The  Rand  study  reports  on  page  15  that  “For  ships, 
MS  B  typically  occurs  before  the  detail  design  and  construction  contract  is  awarded,  but 
after  the  preliminary  and  critical  design  reviews.”  This  is  relevant  when  one  considers 
the  fact  that  MS  C  is  when  C4I  Acquisition  Programs  normally  have  good,  stable  design 
information  (i.e.,  final  Interface  Control  Drawings).  So,  the  New  Construction  Ship  MS  B 
dates  rarely  align  well  with  the  MS  C  dates  for  rapidly  evolving  C4I  systems,  such  as 
CANES.  It  is  in  the  case  where  the  Ship  Construction  milestone  dates  are  misaligned 
with  the  individual  system  acquisition  milestone  dates  where  trade  space  negotiation  with 
the  shipbuilder  is  crucial.  Within  the  context  of  the  DOD  5000  Acquisition  Framework,  a 
better  way  of  merging  the  Shipbuilding  construction  GFI  requirement  milestones  with 
GFI  the  maturity  of  individual  C4I  systems  is  needed. 

B.  THE  CASE  FOR  DESIGN  BUDGET 

The  dilemma  facing  the  Department  of  the  Navy  as  to  whether  to  install  the 
SWAN  on  LPD  28  during  New  Ship  Construction  or  break  up  the  SWAN  and  install 
CANES  for  the  C4I  network  portion  of  SWAN,  speaks  to  the  crucial  issue  of  balancing 
the  early  shipbuilder  GEI  needs  to  support  New  Ship  Construction  vs  individual  system 
GEI  maturity.  This  is  not  a  new  problem.  This  is  an  issue  facing  every  New  Construction 
where  the  construction  timeline  exceeds  five  years.  In  each  case,  a  brand  new  ship  is 
delivered  to  the  Navy  with  obsolete  information  technology  equipment  installed, 
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requiring  costly  upgrades  during  the  first  Post  Delivery  Modernization  AVAIL  window. 
These  costly  upgrades  are  a  source  of  wasted  taxpayer  dollars  and  resources. 

Figure  14  below  shows  how  delaying  the  final  GFI  Required  Delivery  Date 
(RDD)  decreases  information  technology  obsolescence  risk  at  ship  delivery.  For  LPD  28, 
it  should  be  noted  that  the  RFP  release  date  for  LPD  28  is  October  2015,  which  is  just  a 
few  months  after  the  initial  Installation  Requirements  Drawings  (IRDs)  will  be  ready  for 
the  LPD  17  Class  variant  CANES  design.  However,  the  time  between  issuing  the 
Detailed,  Design,  and  Construction  (DD&C)  Contract  to  support  New  Ship  Construction 
and  ship  delivery  is  about  six  years  for  LPD  28.  This  great  period  of  time  is  the  primary 
source  of  obsolescence  risk  for  LPD  28,  as  the  ship  that  will  not  be  delivered  to  the  Navy 
until  2022.  In  the  effort  to  mitigate  information  technology  obsolescence  risk  to  the 
shipboard  network,  a  new  Shipbuilding  Acquisition  Strategy  must  be  implemented  for 
LPD  28. 


The  Case  for  Design  Budget 


Delivery 


A  =  Months  before/after  contract  award 


SCN5 


Figure  14.  The  Case  for  Design  Budget  (from  PEO  C4I  2010) 
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C.  DESIGN  BUDGET  DEFINED 

From  actual  language  proposed  by  PEO  C4I  for  inclusion  in  the  Ship 
Construction  Contract  for  LHD  8,  “Design  Budget”  is  defined  as  the  proeess  by  which 
the  Government  sehedules  the  release  of  final  ship  eompartment  outfitting  speeifieations 
after  target  cost,  target  profit,  ceiling  priee,  and  ship  delivery  sehedule  have  been 
established.  The  primary  goal  of  Design  Budget  is  to  provide  the  U.S.  Navy  with  the 
most  technologically  advanced  C4I  systems  available,  without  ineurring  a  signifieant 
increase  in  shipbuilding  costs  due  to  design  ehanges  or  eonstruction  schedule  impaets. 

The  Design  Budget  approaeh  eharacterizes  the  C4I  system  in  terms  of  parametrie 
values  rather  than  speeific  system  details,  such  as  exact  nomenclature,  size,  weight, 
power.  This  allows  for  eontinued  C4I  system  maturity  and  for  change  to  be 
accommodated  within  the  parametric  budgets  or  boundaries  established  without 
impaeting  the  shipbuilder.  In  essenee.  Design  Budget  allows  advaneed  information 
teehnology  C4I  systems  such  as  CANES  to  evolve  transparently  to  the  shipbuilder.  Erom 
a  briefing  given  in  2010  by  PEO  C4I  to  PEO  Carriers  proposing  that  the  Design  Budget 
Approach  be  adopted  for  inclusion  in  the  CVN  79  Ship  Construction  Contract,  the  core 
tenets  of  Design  Budget  include  the  following; 

•  Establishment  of  Size,  Weight,  and  Power  (SWaP)  envelopes 

•  Phased  delivery  of  GEI  to  the  shipbuilder 

•  Use  of  a  Produetion  Integration  Eacility  (PIP)  to  test  and  integrate  the 
system  and  prepare  it  for  delivery  to  shipbuilder 

•  “Just  in  Time”  delivery  of  GEE  to  the  shipbuilder 

•  Use  of  the  Pre-Planned  Product  Improvement  (P3I)  Proeess  to  allow  for 
smart  C4I  Modernization 

•  Inclusion  of  language  in  the  Shipbuilding  Contract  and  other  Ship 
Program  Aequisition  Doeuments  that  support  the  Design  Budget 
Approach 
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PEO  C4I  Design  Budget  Integration 
Process 
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Platform  Design  Budget  Execution  Plan  (DBEP)  defines  “who,  how,  &  when' 


Figure  15.  High  Level  Overview  of  Design  Budget  Process 

(from  PEO  C412010) 

Figure  15  is  a  depiction  of  the  Design  Budget  Process  for  the  Radio 
Communications  Suite  for  Aircraft  Carriers  (CVN  71  RCOH  and  CVN  77  New 
Construction).  The  Product  PMW,  such  as  the  CANES  Acquisition  Program  Office, 
provides  the  equipment  information  and  hardware  to  the  C41  Integrator.  The  C4I 
Integrator  integrates  the  system  and  provides  the  GFI  and  GEE  to  the  shipbuilder,  so  that 
the  shipbuilder  can  install  the  systems  at  the  shipyard. 

D.  DESIGN  BUDGET  CORE  TENETS 

1 .  Establishment  of  S WaP  Envelopes 

The  Design  Budget  approach  involves  establishing  design  envelopes  for  C4I 

equipment,  which  include  design  parameters  that  cannot  be  exceeded,  such  as  Size, 

Weight,  and  Power  (SWaP)  and  Heating,  Ventilation,  and  Air  Conditioning  (HVAC). 

Establishing  the  SWaP  and  HVAC  design  envelopes  enables  the  shipbuilder  to  proceed 

with  the  design  and  development  of  the  shipboard  spaces  containing  the  C4I  network 

equipment  (and  associated  the  associated  infrastructure,  such  as  wireways,  power,  fan 
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rooms,  and  inter-compartment  cabling)  without  requiring  the  actual  C4I  equipment  to  be 
physically  present  at  the  ship  and  ready  for  installation.  This  approach  provides  much 
greater  flexibility  by  allowing  the  installation  of  the  latest  hardware  versions,  preventing 
the  need  for  costly  equipment  rip-outs  after  ship  delivery. 

2.  Phased  Delivery  of  GFI 

As  mentioned  above,  the  establishment  of  design  envelopes  is  a  core  tenet  of  the 
Design  Budget  Approach.  However,  in  order  for  the  design  envelopes  to  work,  phased 
GFI  must  be  provided  to  the  shipbuilder  to  support  the  shipbuilder’s  effort  to  design, 
procure,  and  plan  for  the  installation  of  long  lead  shipboard  infrastructure  items,  such  as 
power  generation  and  distribution  equipment.  Phased  GFI  products  include  the  following: 

•  Space  arrangements 

•  Parametric  data 

•  Cable  routing  diagrams 

•  Power  diagrams 

•  Equipment  outline  and  mounting  diagrams 

3.  Use  of  a  Production  Integration  Facility  (PIF) 

Every  effort  should  be  made  to  allow  for  the  testing  and  integration  of  C4I 
equipment,  including  network  equipment  racks,  servers,  in  a  land  based  Production 
Integration  Eacility  (PIP)  prior  to  GEE  Delivery  to  the  shipbuilder.  The  primary  objective 
of  the  PIP  is  to  fully  test  and  integrate  the  C4I  equipment  in  an  environment  that  reflects 
the  representative  operational  configuration  onboard  the  designated  ship.  In  the  case  of 
CANES,  this  includes  the  pre-loading  of  all  software  prior  to  GEE  Delivery  to  the 
shipbuilder. 

The  goal  with  the  use  of  the  PIF  is  not  to  duplicate  product  line  testing,  but  to 
ensure  that  the  C4I  capability  to  be  delivered  to  the  shipbuilder  will  be  fully  interoperable 
and  ready  for  installation.  Eand-based  testing  at  the  PIF  brings  a  disciplined  Systems 
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Engineering  approaeh  to  the  shipboard  platform  level  test  and  integration  proeess.  This 
approaeh  results  in  a  fully  tested  and  eertified  system  ready  for  installation. 

4.  Just  in  Time  Delivery  of  GEE  to  the  shipbuilder 

The  Schedule  A  dictates  when  GEE  is  required  for  delivery  to  the  shipbuilder. 
Typically,  the  dates  listed  in  the  Schedule  A  are  driven  by  compartment  availability  based 
on  the  Ship  Construction  schedule.  The  impact  of  locking  in  the  Schedule  A  dates  early 
will  be  that  delivery  of  C4I  equipment  will  be  required  years  in  advance  of  actual  light 
off  This  is  the  primary  driver  of  information  technology  obsolescence  risk. 

One  core  tenet  of  Design  Budget  is  to  deliver  as  late  as  possible  in  the  effort  to 
avoid  information  technology  obsolescence.  One  method  of  satisfying  the  shipbuilder’s 
need  to  land  racks  inside  shipboard  compartments  prior  to  space  closeout  is  to  deliver 
empty  racks  so  that  the  shipbuilder  can  land  the  racks  in  the  respective  space  and  install 
them  on  the  rack  foundations.  This  mitigates  the  issue  of  having  to  cut  an  access  into  a 
space  to  facilitate  bringing  large  equipment  racks  later.  The  ‘Just  in  Time’  delivery  of 
GEE  aspect  of  this  tenet  occurs  when  the  electronic  equipment  to  populate  the  racks  is 
delivered  a  few  months  prior  to  Electronic  Eight  Off  (EEO).  Another  benefit  of  Just  in 
Time  GEE  Delivery  is  that  the  sensitive  C4I  equipment  is  protected  from  exposure  to  the 
harsh  shipyard  environment,  thus  preserving  the  life  of  the  equipment. 

5.  Else  of  Pre-Planned  Product  Improvement  (P3I)  Process 

The  P3I  Process  enables  concurrent  development  of  a  system  and  its  subsystem 
components.  P3I  allows  for  flexibility  in  procurement  when  the  system  life  cycle  and 
Shipbuilding  Project  schedules  do  not  align  well.  In  cases  where  the  C4I  system  is  at 
great  risk  of  being  obsolete,  it  may  make  more  sense  to  have  the  shipbuilder  install  only 
the  required  infrastructure  during  New  Ship  Construction  and  to  defer  the  actual  system 
install  until  after  ship  delivery.  Use  of  the  P3I  Process  in  this  manner  can  avoid  both  the 
risk  of  IT  system  obsolescence  and  the  need  for  costly  equipment  rip-outs  post  ship 
delivery. 


52 


6.  Inclusion  of  Design  Budget  Language  in  the  Ship  Construction  Contract 

The  final  tenet  of  Design  Budget  is  that  aetual  language  be  included  in  the 
Detailed  Design  and  Construetion  (DD&C)  Contract  for  the  ship,  along  with  the  Ship 
Acquisition  Program  documents,  sueh  as  the  Aequisition  Strategy  (AS).  This  is  the  most 
important  of  all  tenets  of  Design  Budget.  For,  if  the  language  is  not  included  in  the 
Shipbuilding  Contract  or  the  Aequisition  doeuments,  there  will  be  no  means  to  exeeute 
Design  Budget  during  the  New  Ship  Construetion  effort. 

E,  BENEFITS  OF  DESIGN  BUDGET 

One  example  that  shows  how  big  a  differenee  that  the  Design  Budget  Approaeh 
ean  make  during  New  Ship  Construetion  is  the  LHD  1  (WASP)  Class  of  Force  Level 
Amphibious  Assault  Ships.  C4I  systems  were  delivered  and  installed  on  LHD  1  -  7  in  the 
eonventional  manner.  However,  the  Design  Budget  Approaeh  was  implemented  on  USS 
MAKIN  ISLAND  (LHD  8).  In  a  PEO  C4I  briefing  given  to  PEO  Ships  by  the  EHD  8 
Integration  Platform  Manager  (IPM)  in  Oetober  of  2010,  it  was  reported  that  the 
implementation  of  Design  Budget  resulted  in  a  90%  reduetion  in  C4I  related  Engineering 
Change  Proposals  (ECPs)  and  an  estimated  cost  savings  of  approximately  $22. 6M.  Here 
are  some  of  the  speeifie  ehallenges  that  PEO  C4I  faeed  during  New  Ship  Construetion  on 
EHD  7  regarding  C4I  systems: 

•  C4I  baseline  design  frozen  at  Shipbuilding  Contraet  Award 

•  C4I  equipment  delivered  fully  populated  and  too  early  in  the  Shipbuilding 
eonstruetion  timeline 

•  C4I  equipment  integration  and  testing  first  oecurred  onboard  ship  and  just 
prior  to  Builder’s  Trials 

•  GEI  was  required  very  early,  foreing  the  delivery  of  obsolete  C4I 
equipment 

•  25  ECPs  were  submitted  regarding  C4I  equipment  design  changes 
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After  implementing  the  Design  Budget  Approaeh  on  LHD  8,  the  eontrast  with 
LHD  7  was  dramatie.  Here  are  a  few  highlights  from  the  LHD  8  New  Ship  Construetion 
effort  that  showease  the  impaet  of  the  Design  Budget  Approach; 

•  Only  three  ECPs  were  submitted  regarding  C4I  equipment  design  changes 

•  C4I  baseline  freeze  date  was  pushed  one  year  to  the  right  of  Contract 
Award 

•  Unpopulated  C4I  equipment  racks  were  delivered  to  support  Ship 
Construction 

•  Just  in  Time  delivery  of  GFE  and  empty  racks  were  populated  later  in  the 
ship  construction  timeline 

•  All  C4I  equipment  was  fully  tested  and  integrated  at  a  land-based  test  site 
prior  to  GEE  delivery  to  the  shipbuilder 

•  GEI  was  delivered  to  the  shipbuilder  in  a  phased  manner 

Clearly,  implementation  of  the  Design  Budget  Approach  had  a  great  impact  on 
USS  MAKIN  ISLAND  (LHD  8).  This  effort  saved  the  taxpayers  a  significant  amount  of 
money  and  preserved  time  and  equipment  resources  for  the  Department  of  the  Navy.  The 
benefits  of  the  Design  Budget  Approach  include  the  following: 

•  Significant  cost  avoidance  for  the  Department  of  the  Navy  and  the 
shipbuilder 

•  Change  can  be  better  accommodated  as  C4I  systems  evolve 

•  Risk  exposure  can  be  minimized 

•  Reduced  total  number  of  Schedule  A  line  items 

•  Reduced  storage  time  for  C4I  equipment  at  the  shipyard 

•  Reduced  exposure  of  sensitive  C4I  equipment  to  industrial  environment 

•  Reduced  number  of  potential  Engineering  Change  Orders  (ECOs)  and 
Engineering  Change  Proposals  (ECPs)  at  the  shipbuilder 

•  Eater  technology  insertion,  decreasing  risk  of  obsolescence 

•  Smaller  scope  tech  refresh  required  during  first  Post  Delivery  AVAIL 

The  Design  Budget  Approach  affords  the  Government  more  flexibility  for 
technology  insertion  so  that  the  right  C4I  system  can  be  delivered  and  installed  at  the 
right  time! 
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F.  CHAPTER  SUMMARY 

The  Design  Budget  Approach  aligns  with  the  Acquisition  Strategy  of  C4I 
systems.  This  is  especially  true  of  shipboard  network  systems,  such  as  CANES.  Design 
Budget  pushes  the  delivery  of  detailed  design  information  to  the  right,  allowing  for  the 
C4I  systems  to  continue  to  mature,  independent  of  New  Ship  Construction.  The  final 
design  GFI  is  delivered  later  in  the  process  to  support  the  integration  of  the  latest  in 
technology  in  meeting  the  shipbuilder’s  construction  schedule. 

Use  of  the  Design  Budget  Approach  affords  the  government  more  flexibility  for 
technology  insertion  on  New  Construction  platforms  and  a  means  to  avoid  information 
technology  equipment  obsolescence.  The  flexibility  for  technology  insertion  and 
obsolescence  avoidance  is  ever  important  in  today’s  budget  constrained  environment. 
Design  Budget  is  a  process  that  when  implemented  during  New  Ship  Construction 
projects,  has  the  power  to  save  significant  amounts  of  money,  while  allowing  the 
shipbuilders  to  deliver  New  Construction  ships  with  the  latest  and  greatest  in  C4I 
technology  capabilities. 
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VI.  CONCLUSION 


A.  INTRODUCTION 

The  Shipboard  Wide  Area  Network  (SWAN)  was  designed  and  built  by  Raytheon 
and  installed  on  the  first  11  ships  of  the  LPD  17  Class.  As  one  of  the  first  major 
Commereially  Furnished  Equipment  (CEE)  shipboard  networks  installed  on  a  New 
Construction  Ship,  it  was  envisioned  to  be  a  holistic  shipboard  network,  integrating 
everything  from  UNCEAS  and  Secret  C4I  network  capabilities  to  Hull,  Mechanical,  and 
Machinery  (HM&E)  network  capabilities.  However,  the  SWAN  was  limited  in 
performance  and  brought  with  it  mounting  sustainment  costs  to  PEO  Ships,  the  Program 
Office  responsible  to  pay  for  life  cycle  sustainment. 

As  a  result  of  a  substantial  projected  sustainment  cost  growth  for  the  SWAN,  on 
04Marll,  the  R3B  tasked  OPNAV  N2/N6  and  OPNAV  N85  (now  N95),  the  EPD  17 
Ship  Resource  Sponsor,  to  conduct  a  study  on  the  LPD  17  Class  Shipboard  Network 
architecture  and  to  provide  a  recommendation  for  the  future.  On  ObAprll,  PEO  Ships 
and  PEO  C4I  formed  a  joint  study  team  and  engaged  to  research  the  LPD  17  Class 
SWAN  and  to  provide  a  recommendation  for  the  future. 

The  final  recommendation  of  the  SWAN  Study  was  that  the  C4I  network  portion 
of  the  SWAN  be  replaced  with  CANES  and  that  the  HM&E  portion  of  SWAN  be 
segregated  and  become  a  POR  network  to  be  managed  by  NAVSEA.  The  study  team’s 
recommendation  was  accepted  by  the  Navy  Leadership  and  approved  for  implementation 
via  the  Navy  Modernization  Process.  The  focus  of  this  research  was  to  consider  the 
viability  of  installing  CANES  during  New  Ship  Construction  on  LPD  28,  the  final  ship  of 
the  LPD  17  Class,  as  opposed  to  the  SWAN. 

B,  SUMMARY  OF  KEY  FINDINGS 

1.  SWAN  sustainment  is  cost  prohibitive  in  the  long  run, 

A  review  of  the  LPD  17  Class  SWAN  Sustainment  Study  revealed  that  the  cost  to 
sustain  the  SWAN  across  the  PY13-  17  EYDP  was  $99M.  On  average,  that  is  about 

$2.5M  per  hull  to  sustain  only  one  shipboard  system  over  a  four  year  period  of  time. 
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Considering  the  fact  that  the  U.S.  Navy  has  275  active  ships  (www.navv.mil)  and  the 
LPD  17  Class  will  have  at  most  10  ships  by  the  end  of  FY17,  this  was  a  significant 
portion  of  the  PEO  Ships  budget  and  of  great  concern  to  Department  of  the  Navy 
leadership.  Growing  concern  over  SWAN  sustainment  costs  was  amplified,  when  the 
increasing  threat  of  cyber  security  vulnerabilities  and  the  unique  training  requirements 
tailored  to  the  SWAN  was  taken  into  account.  Ultimately,  OPNAV  and  ASN  (RDA) 
decided  that  the  status  quo  was  no  longer  tenable  and  approved  a  plan  to  replace  the  C4I 
network  portion  of  SWAN  with  CANES,  the  GEE  POR  shipboard  network  solution. 

2,  Replacing  the  C4I  Network  portion  of  SWAN  with  CANES  is  the  best 
alternative. 

The  LPD  17  Network  Study  team  analyzed  nine  potential  COAs,  which  were 
eventually  down-selected  to  three:  (1)  SWAN  Enclave  Hardware  Expansion  (COA  A); 
(2)  CANES  Eederated  with  NAVSEA  POR  Solution  for  HM&E  (COA  B);  and  (3) 
CANES  Eederated  with  NSWC  CD  POR  Solution  for  HM&E  (COA  C).  After 
conducting  an  extensive  analysis  of  engineering  feasibility,  cost,  and  risk,  the  study  team 
recommended  to  leadership  in  December  2011  that  COA  B  be  adopted.  In  January  of 
2012,  OPNAV  accepted  the  recommendation  and  made  the  decision  to  fund  the  effort  to 
federate  the  SWAN  and  replace  the  C4I  Network  portion  of  SWAN  with  CANES.  This 
decision  made  in  2012  has  been  validated,  as  sustainment  cost  for  SWAN  continue  to 
escalate  and  cyber  vulnerabilities  for  the  older  SWAN  Network  increase.  With  CANES 
successfully  completing  the  Limited  Deployment  Fielding  Phase  of  the  Program,  the 
Navy  is  already  starting  to  realize  increased  C4I  network  capabilities,  greater  protection 
from  cyber  vulnerabilities,  and  greatly  improved  shipboard  network  performance. 

3,  The  SWAN  did  not  have  a  formal  QoS  requirement  for  applications. 

A  major  performance  flaw  for  the  SWAN  was  its  inability  to  guarantee  a 

minimum  level  of  service  for  applications  loaded  on  the  servers  tied  to  the  network.  As 
explained  in  Chapter  III  in  the  CANES  KPP  discussion.  Quality  of  Service  (QoS)  is  a 
measure  of  the  ability  of  a  system  or  process  to  deliver  a  service.  Research  revealed  that 
when  the  SWAN  was  being  designed  at  Raytheon,  consideration  was  never  given  to  have 
a  formal  QoS  requirement  implemented  at  the  application  layer.  In  short,  the  SWAN  was 
designed  with  a  high-speed  backbone  with  edge  switches  that  connect  to  the  backbone. 
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However,  sinee  there  was  no  QoS  speeification  for  the  edge  devices,  the  edge  devices 
worked  on  a  first-come,  first-served  basis.  This  design  flaw  impacted  the  QoS  of 
applications  during  high  periods  of  network  traffic  on  the  SWAN.  The  critical  lesson 
learned  from  the  SWAN  is  that  QoS  specifications  must  always  extend  to  the  application 
layer. 

4.  CANES  has  a  QoS  requirement  at  the  application  layer. 

The  CANES  CDD  lays  out  a  clear  set  of  KPPs,  KSAs,  and  the  Net-Ready  KPP. 
And,  included  in  the  KPPs  is  a  requirement  under  Systems  Management  to  monitor  QoS 
at  the  application  layer.  This  enhanced  feature  of  CANES  to  deliver  QoS  at  the 
application  layer  is  an  item  that  positively  impacts  the  readiness  of  the  warfighter, 
increasing  shipboard  readiness. 

5.  The  CANES  Systems  Engineering  V  Model  was  highly  effective. 

The  CANES  design,  development,  integration,  and  testing  effort  followed  the 
Systems  Engineering  V  Model.  Starting  with  a  clear  Capability  Need  from  the  warfighter, 
and  stable  requirements,  as  set  forth  in  the  CANES  CDD,  the  CANES  SE  Team 
methodically  worked  down  the  left  side  of  the  SE  V,  decomposing  the  requirements  into 
a  detailed  design  on  paper.  Then,  the  SE  Team  methodically  worked  up  the  right  side  of 
the  SE  V,  using  the  Engineering  Development  Model  built  by  the  contractor  to  for 
verification  testing  of  the  established  requirements  in  the  lab,  and  an  actual  CANES 
system  installed  onboard  ship  to  complete  validation  testing  during  an  lOT&E  event. 

6.  GEE  networks  go  through  more  Acquisition  Rigor  than  CEE 
networks. 

An  item  that  this  research  has  revealed  is  that  the  level  of  acquisition  rigor  that 
GEE  systems  must  go  through,  as  mandated  by  DODI  5000,  far  exceeds  any  level  of 
review  that  CEE  systems  must  go  through.  As  was  the  case  with  the  LPD  17  Class  Ships, 
the  shipbuilder  was  under  contract  to  deliver  the  ship  to  Navy.  And,  the  Electronic 
Systems  Integrator  was  on  contract  to  design  and  integrate  the  SWAN  into  the  ship 
during  New  Construction.  So,  only  the  ship  Top  Level  Requirements  were  being  closely 
monitored  by  the  Government  WRT  DOD  5000  Acquisition  requirements,  which  the 
CEE  SWAN  network  did  not  have  to  satisfy.  With  the  proliferation  of  commercial-off- 
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the-shelf  (COTS)  hardware  and  software  in  use  on  Navy  ships,  assuranee  of  satisfaction 
of  warfighter  requirements  and  design  specifications  is  an  item  of  growing  concern. 

7.  Design  Budget  is  a  proven  process  for  avoiding  obsolescence  risk. 

The  Design  Budget  process  has  been  proven  effective  as  a  means  of  avoiding  C4I 
system  obsolescence  risk  and  saving  money  during  New  Ship  Construction.  The  example 
given  in  Chapter  4,  which  compared  the  LHD  7  construction  effort  vs.  the  LHD  8,  shows 
the  dramatic  impact  that  implementing  Design  Budget  can  have  on  New  Ship 
Construction.  The  Design  Budget  Process  ensures  that  the  Navy  is  provided  with  the 
most  up  to  date  C4I  equipment  suite  at  ship  delivery,  which  at  the  same  time 
accommodating  the  shipbuilder’s  need  for  GFI  and  GFE  to  support  Ship  Construction. 

C.  RECOMMENDATIONS 

1.  Install  CANES  on  LPD  28  using  the  Design  Budget  Approach 

Based  on  the  results  of  this  research,  it  is  highly  recommended  that  PEO  Ships 
make  the  decision  to  install  CANES  on  EPD  28  during  New  Ship  Construction.  Though 
the  decision  will  impact  the  shipbuilder,  the  long  term  benefits  gained  will  far  outweigh 
any  short  term  costs.  Implementation  of  the  Design  Budget  Approach  will  help  to 
mitigate  obsolescence  risk  and  minimize  impacts  to  the  shipbuilder.  The  decision  to 
install  CANES  in  line  during  New  Ship  Construction  on  EPD  28,  along  with 
implementation  of  the  Design  Budget  Approach,  will  ensure  that  EPD  28  will  deliver  to 
the  Navy  in  2022  with  the  latest  and  greatest  in  C4I  network  capabilities  installed. 

2.  Mandate  GFE  POR  C4I  solutions  on  all  New  Construction  Ships 

It  is  also  recommended  that  the  Department  of  the  Navy  mandate  that  all  new 
construction  shipbuilding  programs  make  every  effort  to  include  GFE  POR  C4I  systems, 
including  shipboard  networks,  in  each  ship  baseline,  as  opposed  to  CEE  systems.  As 
previously  discussed,  the  inclusion  of  CEE  networks  introduces  growing  sustainment 
costs  that  the  Navy  must  pay.  Mandating  that  GFE  POR  C4I  solutions  be  installed 
leverages  existing  Integrated  Logistical  Support  (ILS)  resources,  such  as  spare  parts, 
training  assets. 

3.  Incorporate  Design  Budget  on  all  New  Construction  Ship  efforts 
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It  is  clear  that  the  Design  Budget  Approaeh  saves  money  and  is  a  proven  way  of 
avoiding  obsolescenee  risk  for  C4I  and  IT  based  systems.  It  is  highly  reeommended  that 
all  Ship  Aequisition  Program  Management  (SHAPM)  offices  include  the  core  tenets  of 
Design  Budget  in  Ship  Aequisition  Strategies  and  supporting  Design  Budget  language  in 
the  aetual  Ship  Construetion  Contraet  when  awarded. 

4.  Review  the  level  of  Acquisition  Rigor  applied  to  CFE  hardware 

Based  on  the  revelation  that  the  SWAN  CFE  network  did  not  require  QoS  at  the 
application  layer,  it  is  also  recommended  that  the  Department  of  the  Navy  eonduct  a 
thorough  review  regarding  the  policies  for  aequiring  all  CFE  systems.  It  is  reeommended 
that  a  review  of  guidelines  be  established  for  procuring  CFE  systems  and  that  a 
requirement  be  levied  that  elear  performance  specifieations  be  established  if  CFE  systems 
are  to  be  required,  when  there  is  no  GEE  system  available.  At  a  minimum,  CFE  systems 
should  be  held  to  the  same  standard  as  an  equivalent  GEE  system.  Otherwise,  the  direct 
cost  comparison  of  GEE  vs  CFE  holds  no  value. 

D.  OPPORTUNITIES  FOR  FOLLOW  ON  RESEARCH 

Building  a  New  Construction  Ship  is  a  complex  project  spanning  multiple  years. 
Effectively  planning  for  the  design,  procurement,  delivery,  test,  integration,  and 
installation  of  eonstantly  evolving  C4I  systems  makes  this  ehallenge  even  greater.  During 
the  eourse  of  this  researeh  effort,  a  number  of  areas  for  follow  on  researeh  were 
identified.  The  top  five  areas  for  follow  on  research  includes: 

•  Use  of  CFE  Networks  to  meet  warfighter  KPP  requirements 

•  Analysis  of  the  cost  to  sustain  the  TSCE  Network  on  ECS 

•  Analysis  of  the  eost  to  sustain  the  TSCE  Network  on  DDG  1000 

•  Eevel  of  oversight  applied  on  Defense  Contraetor  use  of  CFE 

•  Total  Fife  Cycle  Cost  implications  for  CFE 

Based  on  the  review  of  the  SWAN  Sustainment  Study,  further  research  involving 
the  Total  Ship  Computing  Environment  (TSCE),  whieh  is  a  CFE  network  mueh  like  the 
SWAN,  is  warranted.  In  addition,  further  researeh  is  needed  about  the  level  of  aequisition 
rigor  and  oversight  applied  by  the  Government  to  CFE  systems. 
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